When to schedule conflict resolution?

App Development
1

When there’s a conflict between the remote and local versions of a record, I have a function to merge the changes and call storeObject().

When I run this merge function synchronously (from the change event handler) or with queueMicrotask(), I get a second change event with a conflict. If I run the merge function using setTimeout(), I don’t.

Is that the official contract? Conflict resolution can’t happen until the next iteration of the task queue?

2

I would like to understand this as well. Have yet to figure it out.

3

Maybe @michielbdejong could give some insight on the original intent of this API?

4

I think I wrote the original version of that code about 8 years ago, so don’t remember the details. I doubt that was intentional. At the time, Promises didn’t exist yet in JavaScript, and I remember there were some very annoying intricacies about how IndexedDB does its “smart” atomic commit after the last callback returns. That may have something to do with it?

Anyway, yeah, that sounds like a bug :slight_smile:

1 Like
5

Thanks, @michielbdejong!

@DougReeder I guess we could just fix it in the library by using setTimeout() for running the callback then anyway, right?

Edit: Looking at the code, perhaps it’s better to document that using storeObject() or similar within a change handler should be done asynchronously via setTimeout().

6

It’s reasonable to require conflict resolution to be asynchronous. It would be nice to be sure that the next iteration of the task queue is enough delay.

Certainly this should be documented, as it’s part of the contract.

1 Like
7

Documentation pull request:

1 Like