-
Notifications
You must be signed in to change notification settings - Fork 40
Error ingesting resources #34
Comments
Hi @xino12 , Thanks for posting it. Yes, I think it's part of the migration issues. Can you try dropping the Postgres table and re-running cloudquery? |
Hi @yevgenypats I dropped the whole database and recreate it but I got this error now:
|
Hi @xino12, thanks for reporting the issue, we fixed the panic in 0.1.4 of the SDK and updated with v0.3.5 of the provider. Please have a try, it shouldn't crash now. I couldn't replicate the error on my system (I used postgres 13). It should print warning messages instead of errors, so if you see them when the provider initializes, post them here so I can investigate it further. |
I deleted again all aws tables and I see this error now:
|
Okay I see the issue, thanks for the log. I will update a hot fix very soon and update when ready. |
@xino12 can you please tell me the version of postgres you are using? can you also try to drop the specific table aws_ec2_security_group_ip_permissions_egress_user_id_group_pairs? i.e |
I'm using postgres 11, tried deleting but still have the same issue. |
I've tried dropping all tables, let's see if now it does not fail, but it's certainly confusing |
it seems there might be a dependency when creating the tables that somehow you have it relaxed in your local setup and it does fail in other envs |
Okay, I think I found a pattern, it's very long table names what created this mess |
Probably any table name with more than 63 characters will create issues while creating the tables in pgsql 11. |
Yes, I was suspecting it had to do with the pg version. Postgres 13 is a little more flexible, we are currently testing our providers on pg 12/13. We have an open task cloudquery/cq-provider-sdk#9 since this can also occur on long column names. Ill update the table names so they are shorter than 63 bytes. |
🙇🏼 |
Fixed #38 and released in v0.3.6. Added pg 11 to the matrix testing as well, so if this occurs again we will catch it before it happens. Thanks again for helping out in finding this issue! Tell me if it is resolved on your side so I can close this issue :) |
So I see that now all migrations work :) I see errors with assuming roles but I'm closing this issue. Thanks @roneli |
Since April 8th we see an error while ingesting AWS resources.
I guess that's part of the migration to the new SDK? Thanks for the good job as always :D
The text was updated successfully, but these errors were encountered: