nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Child Item

Datastore how to get past sync errors?

Caram

I've just had again this bug about "delete for title: key not present". This happened on a production device, a week before launch, whilst recording a screencast. Sync stopped syncing. This is getting freaky because how is the user going to know and what is he going to do about it? Remove the app? Clearly this is not an acceptable solution. Sync has to be able to sync no matter what. Otherwise the user will loose confidence, stop using the app, write negative reviews and the business will spiral downwards. Sync should be able to get over errors and continue syncing, just like an HTML browser does not choke on a poorly written Web page and manages to get the rest of the page displayed.

How can we improve the current state of affairs? I have a couple of questions/suggestions.

How to clear the sync error without removing the app? Unlinking the account does not suffice currently, the app has to be removed manually.
How to monitor sync errors from an observer?
There will always be bugs in the sync code, so the sync code must become resilient to sync errors, get past them and not just give up. This is in my opinion the most important improvement area.

Caram

Dec 15 09:55:48 iPad Ubibase[1451] <Warning>: [WARNING] status: REQUEST: op.cpp:116: put_delta error response 400: Delete for title: key is not present in {}
Dec 15 09:55:48 iPad Ubibase[1451] <Warning>: [ERROR] db: database_manager.cpp:1354: datastore op PutDeltaOp(dsid=.jDhtK66VQf8aF9fBd1bbrfM4H1uzwKpWWu8OW3zyJ7k, rev=0->1, nonce=BqAtwQz80CKno5RTfA7Jjw) failed: put_delta error response 400: Delete for title: key is not present in {}

Find more posts tagged with

API

Abuse

Comments

Steve M.

Caram, have you found a way to reproduce this error? It's almost certainly a bug in the SDK, but we haven't had luck reproducing it.

Information that might help: which version of the SDK are you on? Are you using local datastores (and then migrating)? Can you share the code/steps that created and modified this datastore? Did you set a title on the datastore and then remove it?

As to your more general question, it's hard to recover from an error like this. The server is correct that the client is sending an invalid delta. The client doesn't know what to do in this case, because it thinks it's sending a valid delta. Doing something drastic like throwing away the local changes (e.g. what happens when you reinstall the app) can easily lead to data loss. There are other possibilities, but fundamentally this is a bug in the SDK that needs to be fixed. I just don't know how to track it down without being able to reproduce it.

Caram

Steve, I don't think I unset any datastore title. I do set title either from user input or from another datastore. There are only the 4 lines in the entire app that do set a datastore title. Do any of these ring a bell?

dupTable.datastore.title = datastore.title
someTable.datastore.title = name # where name is a non empty string
someStore.title = @name
someTable.datastore.title = name # where name == 'New'

We were running pretty wildly through the app this morning during screen casting, no exact record was taken of which exact operations did take place, so I have no way to say how you can reproduce the error. Could it be an assignment of the title to nil or to an empty string?

One thing I remember though is that we tried importing data into a datastore from a file via the Sync SDK. The app crashed at some point during the import due to an unrelated bug (a mapView issue in another thread). Upon restart, we noticed after a while that syncing for this account become problematic. But I am not 100% sure the SDK bug did not already occur before the crash.

Do you any suggestions at this point? Would a copy of the faulty store be of any help?

Caram

SDK 3.1.1

iOS 8.1.1

Steve M.

Caram, you were exactly right. Assigning a null to the title can cause this.

My advice for now is to just make sure you never try to assign a null title. This should make your app completely safe from this bug. We'll take a look on our side at possibly patching the SDK or even making a server-side change to ignore these bogus deltas.

Caram

Thanks Steve, this is reassuring.

As to the more general question, we need to find a way to improve the customer experience. Whatever high the quality of the team, and it is incredibly high indeed, there will always be the next bug; we cannot assume that the user will simply have to stop using the app or reinstall. So, in a situation like this, what are the simple steps that you would recommend to implement in apps/code, that would make the user able to continue working, albeit possibly at the penalty of some, hopefully minor, data loss?

I'm thinking of things like dropping the chain of unsynced deltas. I would like to implement this before releasing the app, if possible. We have better be prepared for the worse than have to deal with it in the field when hours are few and stress is high.

Caram

Steve, there seems to be a further issue.

When I add a new record on the device that has the faulty delta, the record is NOT uploaded to the server and status.uploading remains true (but nothing ever happens).
When I add a new record on another device to the same datastore, that record is downloaded properly by the faulty device.

However, the datastore is NOT the one that has the faulty delta. So it looks like a faulty upload from one datastore blocks uploads from other datastores in the same account. Could this be true?

Steve M.

Yes, Caram, once you have this faulty delta in the queue, I believe no deltas will be uploaded to the server. (That operation will be tried and will fail in a loop forever.)

There's currently no way for you to instruct the SDK to drop deltas that are already in the queue.

Caram

Steve, could you then pass these on as feature requests please? Maybe it goes without saying.

A faulty upload for one datastore should not block valid uploads from other datastores.
There should be a way to cancel pending/faulty uploads.

Thanks.

Steve M.

Thanks as usual for your feedback. Certainly, it all gets passed along to the rest of the team.