Skip to content

Improve error message when a soft-deleted form gets re-submitted #794

Closed
getodk/central-backend
#1316

Description

@dbemke

Action to take

In #794 (comment), we agreed to add an improved error message in Central for this case.

If Central receives a submission with an instanceID it recognizes as being soft-deleted, it should return a new problem and the error text:

This submission has been deleted. You may not resubmit it.

Problem description

Re-submitting a submission which was deleted

URL of the page

https://staging.getodk.cloud/

Steps to reproduce the problem

  1. In Collect send a submission of a form.
  2. In Central delete the submission.
  3. In Collect go to "Ready to send- Change View- Show Sent and UnsentForms”.
  4. Select the sent submission and tap "Send Selected”

Screenshot

sendSentDeletedSub

Expected behavior

From the thread in collect slack- Ln :
"When re-submitting a deleted submission, here are some reasonable outcomes I can think of:

  • Central accepts the submission but doesn’t do anything with it (behavior when a submission isn’t deleted)
  • Central accepts the submission and un-deletes it
  • Central rejects the submission with an error saying the submission has been received and then deleted (similar to the second case but with a better error message)"

Central version shown in version.txt

https://staging.getodk.cloud/
versions:
2e5c4f7 (v2024.2.1-3-g2e5c4f7)
+4a5a9ff81efff48a1500214d9c826b590c9ddaed client (v2024.2.1-16-g4a5a9ff8)
+746ff058d32d968f13cf4e7b0a48b81f88fb21df server (v2024.2.0-79-g746ff058)

Activity

  1. ktuite commented on Nov 22, 2024

    @ktuite
    Member

    I'll look into this... a similar issue was coming up while i was working on #749 / getodk/central-backend#1299

    Basically, what is the behavior when you resubmit a submission that was soft-deleted for both regular submissions like in this issue and for draft submissions? I had been assuming it was simpler than the form delete case for some reason, but it's not. I'm not sure which of the three scenarios @dbemke mentioned is best

    • Central accepts the submission but doesn’t do anything with it (behavior when a submission isn’t deleted)
    • Central accepts the submission and un-deletes it
    • Central rejects the submission with an error saying the submission has been received and then deleted (similar to the second case but with a better error message)"

    In the invisible soft-delete to be able to recover deleted draft submissions, it should probably be the second scenario where you can resubmit that submission or another submission with the same instance id and not have it complain.

  2. self-assigned this
    on Nov 22, 2024
  3. matthew-white commented on Nov 22, 2024

    @matthew-white
    Member

    Not that this was suggested, but I don't think we should allow there to be multiple submissions with the same instance ID, even if one is deleted. Otherwise, we'd have to expose the numeric submissionId for undeleting submissions, similar to how we have to expose formId for undeleting forms. That's because xmlFormId doesn't necessarily uniquely identify forms when you include deleted forms.

    Central rejects the submission with an error saying the submission has been received and then deleted (similar to the second case but with a better error message)

    I think this would be the easiest thing to do. I also like that it's explicit about what the situation is. Could we run with this, then see how often this situation comes up?

  4. lognaturel commented on Nov 22, 2024

    @lognaturel
    Member

    Could we run with this, then see how often this situation comes up?

    That seems reasonable! Do you think Central should be responsible for the better error message or Collect? I can't remember, are we currently sending the error code (e.g. 409.2) in any way?

  5. lognaturel commented on Nov 22, 2024

    @lognaturel
    Member

    I think it would be reasonable for Central to have a special message like "This submission was previously received and deleted." If we want to be more precise, we could go with something like "The ID of this submission matches the ID of a deleted submission." but I don't think that's as helpful for users.

    Alternatively, we'd want to have a special code that Collect can detect that is just about this deleted match case.

  6. matthew-white commented on Nov 22, 2024

    @matthew-white
    Member

    Do you think Central should be responsible for the better error message or Collect?

    No strong feelings, but it kind of feels like a server concern to me. Central already returns specific Problems for uniqueness violations that we know can happen in the course of normal Central usage. For example, if you try to publish a form def with a duplicate version string, that's a specific Problem with a more informative error message (a 409.6). I think we should do something similar in this case.

    are we currently sending the error code (e.g. 409.2) in any way?

    I'm not 100% sure, but I don't think we send it over OpenRosa. From what I can tell, it'd be easy to do so though.

  7. lognaturel commented on Nov 22, 2024

    @lognaturel
    Member

    that's a specific Problem with a more informative error message (a 409.6). I think we should do something similar in this case.

    Perfect, let's do that.

    I don't think we send it over OpenRosa. From what I can tell, it'd be easy to do so though.

    I think we should to give clients the option of having their own localized and potentially more detailed error messages. That will probably be a whole separate project, though, and we don't have to do it now.

  8. matthew-white commented on Nov 22, 2024

    @matthew-white
    Member

    I think we should to give clients the option of having their own localized and potentially more detailed error messages.

    I personally feel like we would benefit from having server-side localization at some point. Both error messages and emails would benefit from being localized. If Backend did more localization, then Frontend would have less of that homework (#489). More to the current point, clients like Collect could tell Backend what locale they prefer for error messages via the Accept-Language header.

    That will probably be a whole separate project, though, and we don't have to do it now.

    Sounds good. 👍 Seeing localized error messages in the client definitely sound like a nice thing at some point.

  9. changed the title [-]Re-submitting a submission which was deleted[/-] [+]Improve error message when a soft-deleted form gets re-submitted[/+] on Nov 26, 2024
  10. lognaturel commented on Nov 26, 2024

    @lognaturel
    Member

    Proposed error text: "This submission has been deleted. You may not resubmit it."

  11. self-assigned this
    on Dec 2, 2024
  12. sadiqkhoja commented on Dec 3, 2024

    @sadiqkhoja
    Contributor

    @lognaturel I am assuming this is only needed for OpenRosa endpoint, right? For REST endpoint we don't allow resubmissions.

  13. lognaturel commented on Dec 3, 2024

    @lognaturel
    Member

    Sounds right!

  14. moved this from 🕒 backlog to ✏️ in progress in ODK Centralon Dec 3, 2024
  15. moved this from ✏️ in progress to ✅ done in ODK Centralon Dec 5, 2024
  16. srujner commented on Dec 6, 2024

    @srujner

    Tested with Success!

  17. added
    behavior verifiedBehavior has been manually verified
    and removed on Dec 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

backendRequires a change to the API serverbehavior verifiedBehavior has been manually verified

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions