A form designed to create one entity (participants, Access all Entities) and update another (consents, Only access own Entities) works as expected most of the time. However, 2 out of 124 submissions mysteriously failed to create/update the associated entities. The 2 failed submissions originated from 2 different devices set with 2 different app users. Both devices/app users successfully submitted submissions with entity creation/updates before and after the failure. The discrepancy can only be identified when comparing the total number of submissions against the number of participant entities created; looking more in depth there were indeed 2 QR codes scanned in submissions that did not appear in the participant entities; the corresponding consent entities were also not updated with the "done" flag.
ODK Central version: v2025.4.4
2. What steps can we take to reproduce this issue?
Not sure, as the issue may be intermittent or triggered by specific conditions which I have not been able to identify.
3. What have you tried to fix the issue?
I recreated the submissions on ODK Collect v2026.1.2 with the same app users (as consent selection set with only access own entity) using the failed submission data stored on ODK Central . Entities were correctly created/updated. I am still waiting for the confirmation of the versions of ODK Collect used in the field.
4. Upload any forms or screenshots you can share publicly below.
Can share privately if you believe anything in the form design may trigger the failure
If you haven't already, can you please go to the detail page for the submissions that weren't processed on Central and share any processing errors you see there?
oh indeed (had never checked these! will do more often) the error message is always the same with actually one more failure occurrence (server now updated to v2026.1.1) so 3 failure out 194 submissions in total
”Failed to process 2 entities in submission due to 1 errors: (Entity 1) Required parameter uuid missing.”
My entities sheet is as below; does this mean the participants entity creation is failing because no entity uuid is provided when the submission is sent?
We're going to be working on showing these in a more useful/loud way and will ask you for feedback once we have some concrete ideas on how. This definitely becomes more of an issue with multiple Entity declarations per form because as we've discussed elsewhere, Central halts Entity processing of the whole submission when it reaches an error.
You might want to start by looking at the raw submission data to see exactly which Entity directive caused the issue. Currently this is annoying to do -- go to the submission details page, add /v1/ after your base server URL and then add .xml at the end of the address. That should give you raw XML to look at (not pretty!). If you search for "entity", you should find an Entity block with id="".
My guess is that ${to_do} can sometimes be blank. It's pretty easy to accidentally create such a case if there's logic involved in determining whether a specific submission is a create or update. If that's lining up with the submission XML, you could try to track that down in your form or send me the form privately to analyze.
It could also be related to the participants Entity but I don't have any hypothesis as to what would be going on in that case. It's true that "Entity 1" suggests that would be the one causing the issue.
so now I can confirm you that it is indeed the participant entity creation which is failing (and not the consent entity update, to_do is the output from select_one_from_file consents.csv with a choice_filter so should only select existing entities or display an empty list if the choice filter condition is not met).
We have been trying hard to reproduce but still have had no luck. Can you please share the form either here if it can be public or in a private message? Sending me a submission privately would also be very helpful.
CC @Grzesiek2010@dbemke if you think of anything else that would be helpful to know.
I've also spun out a thread for what @ahblake brought up here.
Thanks so much for sharing your issues and observations as you experiment with this new functionality, it's very helpful. Please keep sharing if you experiment anything unexpected.
@Thalie, @Grzesiek2010 has identified an issue where a form containing multiple Entity declarations, including some that may be non-relevant, is saved as a draft either automatically or manually and then reopened for further edits. In the form that you shared, it is possible for one of the Entity declarations to be non-relevant. We believe that the 2 data collectors experienced something that made them save as draft while it was non-relevant and then reopened the form.
Here are some possible ways that could have happened:
the user stayed on one screen for a long time and Collect was killed by Android
the participant had to interrupt the interview so the data collector saved and exited the form
Collect crashed
Do any of those seem plausible to you? To reproduce, fill out some values in such a way that ${to_do} in your private form is still blank, save, exit the form, reopen the draft, complete the form and submit.
This issue only affects multiple Entity declarations with relevance. We consider it serious and are working on a point release as soon as possible.
Thanks so much to you and @Grzesiek2010 for digging into this and identifying root causes , it was quite sneaky with this combination of the form structure (temporary non-relevance being there only to control the pacing of simultaneously displayed information) and user interaction with Collect involving incomplete draft saving with non-relevant entity declarations.
All three scenarios you mentioned would be quite plausible. I have personally seen Collect crashing on one of the Android tablets being used for collecting these data (quite old Android I must say - 2011 model), and workflows can be interrupted (especially if interviews are conducted by phone). Let me check with the team to confirm which scenario(s) they have encountered in practice. In the database, I have 10 of these failed entities out of 360 submissions, so roughly 1-2 per week.
, it was quite sneaky with this combination of the form structure (temporary non-relevance being there only to control the pacing of simultaneously displayed information) and user interaction with Collect involving incomplete draft saving with non-relevant entity declarations.