Cannot submit record in offline-capable view due to existing record error

[Apotischman]

Describe the bug
When a user fills out a form with multiple Participant ID fields. the form will not allow the user to submit. The issue will occur if 1 participant ID field is filled out, or all are filled out. The error states "This record name or ID already exists."

To Reproduce
Steps to reproduce the behavior. If applicable please include the smallest possible XLSForm or XForm (as zip or link).

1. Go to an offline form with Participant ID fields
2. Fill out at least 1 Participant ID field
3. Click "Submit"
4. See error

Note: The form only appears to error if there are multiple groupings in the body. I have tested just having the participant id fields being in 1 group, and another question not being in any group. This works correctly. If the question is included in a group, it fails.

Record_exists_multiple_groups.txt

Expected behavior
The form should make it to the submission queue"

Screenshots

[Apotischman]

This might be localized to my Chrome browser. It doesn't occur in Firefox.

[Apotischman]

Here is the console

[MartijnR]

http://localhost:8005/x/full/participant/4c3d9fc2bd39ce3e5e13176075e7ec29?ecid=1

See also email sent on 4/28 with subject "Multiple issues"

I've seen this issue before. I believe it doesn't have anything to do with the form definition, and it cannot be reproduced so far. Once we can reproduce it reliably, we can fix it. I may have to add the record ID to the error message as I believe that may be the only way to figure this out.

• check all db entries created by saving a record (for this form), and try to determine a possible cause of a re-used key (auto-save?, last-saved?)
• add record ID to error message.

[MartijnR]

Happened to run across this and was able to investigate. The cause is a duplicate recordName (not instanceID). Interestingly these records were for a different form (the form had the same form title).

reproduced with http://localhost:8005/x/full/participant/9c4e3730b579618300560a13971d7f2e?ecid=1no

[MartijnR]

The above means that the bug can be bypassed by:

1. saving as draft first, and editing the record name
2. loading the saved record and submitting it

issue reported here: enketo#1010

Some options to resolve:

1. add another postfix (random string 2 or 3 characters) to record name
2. like previous but add the Enketo ID itself as the postfix or prefix (and hide it from the user in the form list?)
3. change database schema to no longer require record name to be unique (we haven't updated a database schema before, might be complicated)
4. like previous but roll our own uniqueness check that only looks at records under the same Enketo ID
5. change database schema to require uniqueness of record name + enketo ID
6. prompt users to edit the record name when this occurs
7. Since the record name is quite irrelevant for a finalized record (since it cannot be opened), we could do one of the above prefixes and postfixes only for finalized records..

• PR to enketo/enketo-express probably For offline-capable views, require unique record name + enketo ID and prompt users to edit record name in case of collision enketo/enketo-express#417

[MartijnR]

Looks like db.js does not support the schema changes. There is a 6 year old unreviewed PR that would add it: aaronpowell/db.js#183. Db.js also doesn't seem to expose the native indexedDb stuff sufficiently to do this ourselves using the native API.

[MartijnR]

pending PR review and merge in enketo/enketo-express

[MartijnR]

• duplicate code changes fro controller-webform.js to controller-webform-oc.js