amplify-js: DataStore generated sync query results in error "InternalFailure"
DataStore does not work. Spending hours I have identified the following root cause, which renders DataStore unusable due to downstream problems.
Describe the bug
I have several tables defined in my schema.graphql. The generated listX queries all work, but there is one syncX query that fails:
query op{
syncCompanies{
items {
id
}
}
}
results in
{
"data": {
"syncCompanies": null
},
"errors": [
{
"path": [
"syncCompanies"
],
"data": null,
"errorType": "InternalFailure",
"errorInfo": null,
"locations": [
{
"line": 30,
"column": 3,
"sourceName": null
}
],
"message": "An internal error occurred."
}
]
}
All other syncX queries do work (in the AppSync console and from the App). There is no custom configuration from my side, everything is generated by amplify.
Generated schema in AppSync does not look suspicious.
What does error location (line 30 column 3) refer to in the error message?
To Reproduce ?
What is Configured?
const awsmobile = {
"aws_project_region": "eu-central-1",
"aws_cognito_identity_pool_id": "eu-central-1:bfa2c3b8-29ab-48bf-b31a-c203c91d12c6",
"aws_cognito_region": "eu-central-1",
"aws_user_pools_id": "eu-central-1_9ZshJoqYZ",
"aws_user_pools_web_client_id": "3c8vqgilt6lrsfgms1llg7g19h",
"oauth": {},
"aws_appsync_graphqlEndpoint": "https://efijlzxctre73fh7wyypkp7fra.appsync-api.eu-central-1.amazonaws.com/graphql",
"aws_appsync_region": "eu-central-1",
"aws_appsync_authenticationType": "AMAZON_COGNITO_USER_POOLS",
"aws_cloud_logic_custom": [
{
"name": "stripewebhook",
"endpoint": "https://6psqnj6s9c.execute-api.eu-central-1.amazonaws.com/dev",
"region": "eu-central-1"
},
{
"name": "webhookapi",
"endpoint": "https://tz7i5kj70b.execute-api.eu-central-1.amazonaws.com/dev",
"region": "eu-central-1"
}
],
"aws_user_files_s3_bucket": "soda-vc149343e68e240dba511955bd41c8b00-dev",
"aws_user_files_s3_bucket_region": "eu-central-1",
"aws_mobile_analytics_app_id": "878cd812fb51425994f875846259b61b",
"aws_mobile_analytics_app_region": "eu-central-1"
};
Environment
System: OS: macOS 10.15.6 CPU: (8) x64 Intel(R) Core(TM) i5-8279U CPU @ 2.40GHz Memory: 337.63 MB / 16.00 GB Shell: 5.7.1 - /bin/zsh Binaries: Node: 14.8.0 - /usr/local/bin/node Yarn: 1.22.4 - /usr/local/bin/yarn npm: 6.14.7 - /usr/local/bin/npm Browsers: Chrome: 85.0.4183.83 Firefox: 80.0.1 Safari: 13.1.2 npmPackages: @mdi/font: ^4.4.95 => 4.9.95 @vue/cli-plugin-babel: ^3.4.0 => 3.12.1 @vue/cli-plugin-eslint: ^3.4.0 => 3.12.1 @vue/cli-service: ^3.4.0 => 3.12.1 aws-amplify: ^3.0.24 => 3.0.24 aws-amplify-vue: ^2.1.2 => 2.1.2 babel-eslint: ^10.0.1 => 10.1.0 eslint: ^5.8.0 => 5.16.0 eslint-config-eslint: ^5.0.1 => 5.0.1 eslint-plugin-vue: ^5.2.3 => 5.2.3 eslint-plugin-vuetify: ^1.0.0-beta.3 => 1.0.0-beta.7 file-loader: ^4.1.0 => 4.3.0 graphql-tag: ^2.9.0 => 2.11.0 js-search: ^1.4.2 => 1.4.3 js-yaml-loader: ^1.2.2 => 1.2.2 jsondiffpatch: ^0.4.1 => 0.4.1 markdown-it: ^10.0.0 => 10.0.0 markdown-it-icons: ^0.4.1 => 0.4.1 material-components-web: ^0.35.0 => 0.35.2 moment: ^2.24.0 => 2.27.0 pdfmake: ^0.1.56 => 0.1.68 pdfmake-unicode: ^0.0.1 => 0.0.1 sass: ^1.22.12 => 1.26.10 sass-loader: ^7.0.1 => 7.3.1 stylus: ^0.54.5 => 0.54.8 stylus-loader: ^3.0.1 => 3.0.2 vue: ^2.6.10 => 2.6.12 vue-cli-plugin-vuetify: ^0.4.6 => 0.4.6 vue-event-hub: ^1.0.2 => 1.0.3 vue-mdc-adapter: ^0.15.0 => 0.15.4 vue-moment: ^4.0.0 => 4.1.0 vue-router: ^3.0.2 => 3.4.3 vue-template-compiler: ^2.5.21 => 2.6.12 vuetify: 2.0.16 => 2.0.16 vuetify-loader: ^1.0.5 => 1.6.0 vuex: ^3.1.0 => 3.5.1 xlsx: ^0.14.2 => 0.14.5 npmGlobalPackages: @aws-amplify/cli: 4.27.3 electron: 1.8.8 marked: 1.1.0 npm: 6.14.7 orca: 1.2.1Additional context
We are in the process of integrating DataStore into our product. We started off before DataStore was available and we need a migration plan. (We already know how to port our queries to support the new generated schema directly by taking into account columns _version and _deleted into account, and this approach works.) Raw data in DynamoDB has been touched to pre-fill _version and _lastUpdated columns after enabling DataStore for entire API.
Due to above mentioned process, the DataStore is broken in such a way that syncing into client works for some tables but not for most (for instance await DataStore.query(Userdata) will fetch records, while await DataStore.query(Process) won’t.) Syncing from client to backend does not work for any table (e.g. await DataStore.query(new Userdata({'fullname':'ABC'})) will put the entity into local storage but the new item won’t be synced). This is probably because the failure of the above query messes up the initialization process of the DataStore client side?
Any help is much appreciated!
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 3
- Comments: 27 (7 by maintainers)
@iartemiev More data to my problem:
latest _versionolder _versionI have posted a longer description of my issue in the CLI project: https://github.com/aws-amplify/amplify-cli/issues/7076
@rsousa you can follow this GitHub issue. We’ll update it once the AppSync bug fix has been deployed.
@peterjungx Closing this issue for now as we have not heard back from you in over a week to confirm if any of the fixes mentioned above have helped to resolve your issue. If you’re still experiencing this issue even after the fix by the AppSync team, please comment to let us know and we will re-open.
However, we’d like to continue looking into any related/similar issues such as the one mentioned by @LaurentEscalier regarding the empty objects. If anyone else is still experiencing this behavior please open your own issue and fill out the Bug Report form with any relevant information such as the model definition causing the error to help us with our reproduction of your particular issue.
Thank you!
FWIW we had to abandon amplify for an unrelated reason, so we are no longer “waiting” on this.
Good luck!
Hi 👋 Sorry this was auto-closed by stale bot. We are working towards preventing this from happening in the future. Please let us know if you are still experiencing this issue and in need of assistance.
not stale. we still have to check our way around this.
By the way this seems to also fail when the value is an empty map
{}: