Amplify-ios: Error: "The key __typename was not found" when using DataStore with existing data in database.

[spenceps]

Describe the bug
If the api is created without enabling conflict detection and data is saved to the backend using the API plugin then after conflict detection is added DataStore fails with The key __typename was not found

To Reproduce
Steps to reproduce the behavior:

1. Create new api as described in the tutorials using amplify cli - amplify api add without enabling conflict detection under the advanced settings option
2. push changes amplify push
3. Save data to the backend using Amplify.API.mutate function
4. Use the Amplify CLI to edit the conflict detection settings. amplify update api
5. push changes amplify push
6. Use the Amplify.DataStore api to fetch data. Amplify.DataStore.query
7. Error is shown in console and data is not synced from backend:

APIError: failed to process graphqlResponseData
Caused by:
DataStoreError: The key `__typename` was not found
Recovery suggestion: Check if the parsed JSON contains the expected `__typename`

Expected behavior
The data to sync from the backend
Environment(please complete the following information):

• Amplify Framework Version: 1.0
• Dependency Manager: Cocoapods
• Swift Version : 5.1

Device Information (please complete the following information):

• Device: Simulator
• iOS Version: iOS 13

[amuresia]

+1

[jfcadillo951]

+1, same error

[drochetti]

@spenceps @amuresia @jfcadillo951 does any of you remember and can provide details on how you inserted the data previously in the DataBase?

Was it using the AppSyncClient SDK? Or using Amplify Console? Or using the DynamoDB UI?

[spenceps]

@drochetti - I was using the AppSyncClient SDK. i.e. Amplify.API.mutate()

[amuresia]

@drochetti for me it was via the Amplify Console and via the mobile DataStore library.

[drochetti]

@drochetti - I was using the AppSyncClient SDK. i.e. Amplify.API.mutate()

Amplify.API.mutate is not AppSyncClient SDK, it's Amplify.

Did you created all the data previously in the DataBase using Amplify and ended up with data without __typename?

[spenceps]

@drochetti - I did create all the data with Amplify. I don't remember if __typename was in the DynamoDB and I have since deleted the data.

[kwomackcodes]

+1, Also experiencing this issue.

[wooj2]

I ran into this as well.

Seems like when conflict resolution is not turned on, the associated dynamo table has the following fields:

• id
• __typename
• createdAt
• updatedAt
• Any other custom fields that the model might have

Once conflict resolution is turned on, (and making a mutation), two additional fields show up for each entry of the model:

• _lastChangedAt
• _version

I guess the use case would be if someone was using Amplify.API with GraphQL w/out conflict resolution turned on.. then made a bunch of mutations, and then decided, that they wanted to move to using Amplify.Datastore.

To work around this, I would imagine that after you've turned on conflict resolution, you could backfill the data so that all entries have a _lastChangedAt and _version field. I haven't tried it-- but I imagine it would work. (Don't do this!!!!) Another option would be to remove all the items from the dynamo db table and then turn on conflict resolution, but, again, probably not a good idea unless you want to delete all the entries in your dynamo table.

Just curious: Is there anyone on this thread has any use case with regards to toggling conflict resolution on and off, or did we run into this bug because we were exploring the differences between API and Datastore?

[wooj2]

Opened up an issue against CLI: https://github.com/aws-amplify/amplify-cli/issues/4690 to support customers who are using API (GraphQL) and moving to Datastore

[royjit]

CLI gh issue was closed because this needs more details design and require investigating all the use cases and side effects. I will keep this ticket open and will update here when we have more info.

[brightfuture]

i've been using admin UI and have the same issue
is there any workaround on this ?

[lawmicha]

Hi @brightfuture, could you expand on the steps that you took through the Admin UI to get into the same state? My understanding of the problem is

1. Make API calls using Amplify.API without conflict resolution
2. Enable conflict resolution on the API
3. Add DataStore to the app, then the data without conflict resolution fields will fail to sync from the cloud

I thought Admin UI gets you to persist directly to DataStore right from the beginning. Feel free to open another issue if you have more details and it does not sound like this is the same issue. The current workaround as @wooj2 mentioned, the data needs to be fixed or deleted. If you are in development, I would suggest removing the items from the DynamoDB table, then no data will be synced from the cloud, and as you write data using Amplify.DataStore, it will automatically sync to the cloud.

[brightfuture]

@lawmicha i can't recall clearly what happened
i couldn't find a fix so i deleted the project and created a new one
so i can't recreate the problem

i think it was because i made changes to DynamoDB from Python Lambda function
and that function didn't seem to be compatible with how Amplify mutates data in DynamoDB
thus cause incompatibility

[palpatim]

made changes to DynamoDB from Python Lambda function

That would definitely cause issues. By default, direct updates to the backing DDB tables would not trigger any subscriptions, since AppSync isn't aware that the data has been modified. Secondly, mutations have particular constructions including version control and conflict resolution fields that have to be kept in sync. Thirdly, if you do have DataStore syncing enabled, updates posted directly to DDB would bypass the sync tables that we use to keep track of updates to a record, meaning that even if you do store the value in the DDB table correctly, you wouldn't necessarily see it in your application if it does a "sync" query--only a full query would return the posted value.

The recommendation for DDB tables backing DataStore applications is to always post mutations via DataStore, or via well-structured queries through the AppSync GraphQL endpoint.

[brightfuture]

@palpatim thanks for the explaination!
it looks like performing backend logic with anything other than NodeJS is fairly difficult atm
i really wish this could be improved soon
currently Amplify is too much frontend centered, i can hardly do anything automatically on the backend

[palpatim]

@brightfuture It would be great to start a discussion about this so we can dig into the use cases you're trying to accomplish. From there, we can think how we might be able to either enable them with framework or CLI features, or at least provide better guidance to folks like you who want to support backend workloads that leverage the persisted models.

[github-actions[bot]]

This issue is stale because it has been open for 14 days with no activity. Please, provide an update or it will be automatically closed in 7 days.

[github-actions[bot]]

This issue is being automatically closed due to inactivity. If you believe it was closed by mistake, provide an update and re-open it.