Datastore fails to sync over missing model

Describe the bug 1 - I have a many-to-many relationship 2 - I trigger a save event on my models using datastore save method 3 - Something happens and a ‘child’ model fails to be saved after the ‘link’ model have been saved

Now, datastore fails to sync at all, not only the affected model, but all models, over all users, at any location.

The failed graphql sync query returns a 200 status code with the error: Cannot return null for non-nullable type: 'Component' within parent 'ChildComponent' (/syncChildComponents/items[757]/parent)

The error is not captured by the error handler callback defined on datastore configuration, nor a hub event is dispatched informing me about the error.

Nothing really happens, datastore fails to work, silently, until I try to dispatch a (complex) save operation just to find out that my db is in an inconsistent state and the work will not be synced.

Clearing the local does not have any effect as datastore tries to sync over the, now inconsistent, db state and gets stuck.

The only fix that worked for me until now is to clear my entire dynamo table, which is not really viable.

To Reproduce Steps to reproduce the behavior:

1. Save a parent model to datastore
2. Save a link model pointing to a parent model and a child model that will never be saved
3. Do not save the correspondent child model
4. Try to sync datastore with Datastore.start()
5. Cry tears of blood…

Expected behavior Datastore should be robust to inconsistent entries, skip the failed models and sync all other data. It should, preferentially, warn me about the failed model, either on the error handler callback and / or by dispatching a hub event over datastore channel. The event should contain enough information so I can take the appropriated action in order to make my db consistent again. It should NOT fail silently.

Code Snippet schema

Component @model
{
  id: ID!
  children: [ChildComponent]  @connection(keyName: "byChild", fields: ["id"])
}

ChildComponent @model(queries: null)
@key(name: "byChild", fields: ["parentID", "childID"])
@key(name: "byParent", fields: ["childID", "parentID"])
{
  id: ID!
  parentID: ID!
  childID: ID!
  parent: Component! @connection(fields: ["parentID"])
  child: Component! @connection(fields: ["childID"])
}

Please, give me some advice on a better temporary solution. Removing datastore from my application would be a big pain at this point and I cannot risk losing data every time a client have a internet failure.

Thanks.

EDIT:

As a workaround, for visibility, I’m now calling Datastore.start() every time my application starts and maintaining a flag synced with hub events. If no ready event is dispatched, I know Datastore sync is not working. However, this does not solves the DB inconsistency problems. Is there any way for me to find out which record is missing without performing a full, multiple table, scan?

Cheers.

[naripok]

Hi, @wei,

Take this one by example.

I tried to reproduce with the offline network sim on dev tools, but didn’t have any luck. The easiest way to reproduce the bug is to run the client, wait for datastore to finish syncing the models, then you delete some of then directly from the dynamo table.

As my application saves 1k-2k models at a time, and a lot of then are not direct parent-child, but data contained on the nodes, and considering the fact that this bug affected me like 6 or 7 times by now, I suspect the problem should be correlated with the order that the models are being synced and the time between the syncing of the link and the relevant nodes.

For instance, when chrome shows any problems and closes itself, as sometimes happens, and the indexedDB state gets messed, this problem arises.

I realize this was not much of a help, so I’m sorry.

[github-actions[bot]]

This issue has been automatically locked since there hasn’t been any recent activity after it was closed. Please open a new issue for related bugs.

Looking for a help forum? We recommend joining the Amplify Community Discord server *-help channels or Discussions for those types of questions.