Sending second update of the entity as the first one - registration form with "Problem processing Entity Query returns an unexpected result."

[dbemke]

Problem description

I locally created an entity and updated it twice (in Collect), then I sent the second update first so that it creates the entity in Central. Afterwards I sent the first update and the registration form as the last one. In the submission detail page of the registration form there is information "Problem processing Entity Query returns an unexpected result."
And I'm not sure if there should be a conflict after sending the second update (the first update created the entity in Central)?

URL of the page

e.g. https://staging.getodk.cloud/#/projects/101/app-users

Steps to reproduce the problem

1. In Collect add user e.g "cacti” https://staging.getodk.cloud/#/projects/101/app-users
2. Set auto send to "off”.
3. Fill and finalize Cactus registration form.
4. Go to Cactus monitoring an update the created entity, finalize the form.
5. Go to Cactus monitoring an update the same entity again, finalize the form.
6. Go to "Ready to send” and select the form with the second update -cactus monitoring and send it.
7. Wait for force-processing the submission/entity in the backlog.
8. When the entity is created in Central, go to Collect and send the first update form (cactus monitoring).
9. Send the cactus registration form

Screenshot

Registration form submision detail page

Expected behavior

I'm not sure what is the expected result

Central version shown in version.txt

https://staging.getodk.cloud/
versions:
51a3e10 (v2024.2.1-4-g51a3e10)
+bb2b2325c5fde4e1325e0d0fcec9c3db6a58cfd7 client (v2024.2.1-35-gbb2b2325)
+57c4da581a21928eb21fef8097f72870af6e4d4d server (v2024.2.0-83-g57c4da58)

[matthew-white]

@ktuite, this might be a good one for you to look into if you have time.

I locally created an entity and updated it twice (in Collect), then I sent the second update first so that it creates the entity in Central. Afterwards I sent the first update and the registration form as the last one. … I'm not sure if there should be a conflict after sending the second update (the first update created the entity in Central)?

I wanted to leave a comment about this part. If you submit the second update first, then the first update, then lastly the entity create (the registration form), then only the entity create should be marked as a conflict. There are exactly three situations in which a new entity version is supposed to be marked as a conflict, which are described in #805. The first two entity versions from the two updates don't match any of the three situations, but v3 of the entity (from the entity create) matches situation 2. Here are the three situations (out of order, simplest to more involved):

• Situation 2. It's a conflict if an offline entity create was delayed, then later applied as an update. This situation applies to the entity create (v3).
• Situation 3. This has to do with whether the offline branch was interrupted by an update from another source (e.g., a second branch from another device, or an update from Frontend). Here, because the two offline updates from the branch came one after another, that's not a conflict.
• Situation 1. It's a conflict if the base version of an entity update is different from the current version on the server. That's the classic, original rule for entity conflicts, but it's a little more complicated here. When the first update comes in (resulting in v2), its base version in the offline branch (i.e., the entity create) is not present on the server. In that case, the server sets the base version to the current version on the server. It is not marked as a conflict. Next, when the entity create comes in (resulting in v3), that wouldn't normally have a base version (an entity create is usually v1). However, when the entity create is applied as an update, the server sets its base version to the current version on the server. It is not considered a conflict due to this situation, since the base version matches the current version. However, again, it is a conflict due to situation 2. One theme I want to point out, which is discussed in more detail in #805, is that force-processing by itself does not automatically result in a conflict. One of the three situations has to apply for it to be a conflict.

[dbemke]

Tested with success!

[WKobus]

Tested with success!