-
Notifications
You must be signed in to change notification settings - Fork 152
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changing to create entities on receipt: reprocessing submissions that resulted in an entity.error #547
Comments
Not sure where to note this, but this issues seems like an OK place. While investigating this comment from another PR about testing that the last version of a submission is what is used in the convert-pending-submissions process, I noted this scenario:
Maybe the event should know the state of the dataset's approval flag at the time the submission came in? Maybe the previous events should get voided or something? |
Trying to capture some thoughts I had while writing tests to emulate the scenarios @matthew-white described above.
To be discussed more later! |
We decided in the Central meeting today to try to exclude submissions that led to an I can add that to my PR (getodk/central-backend#1049) that currently just tests the scenarios above. |
We also decided in the meeting not to worry too much about a change to the |
Right now, when you configure an entity list to create entities on submission receipt, you have the option to process pending submissions. Submissions that have already created or updated an entity are not reprocessed. However, I'm noticing that submissions that were processed, but resulted in a processing error (an
entity.error
event) are reprocessed. I don't think that matters much for submissions that create entities, but I think it has more potential for unexpected outcomes for submissions that update entities.As noted in getodk/central-backend#1044, it's not known before a submission is processed for entities whether it will have an effect on entities at all, and if it will, whether it's to create or update an entity. Processing pending submissions may process submissions that update entities. I agree with the reasoning in the PR that that's not an issue. However, I think it's more of an issue if such a submission is reprocessed, and that reprocessing is successful even when the first attempt at processing failed.
Steps to reproduce the problem
Set things up:
Set up a problematic submission that tries to create an entity:
entity.error
.Set up up a problematic submission that tries to update an entity:
entity.error
.Observe that problematic submissions are reprocessed:
entity.error
s.URL of the page
Expected behavior
I'm not sure what the right behavior is. Maybe it's actually nice that if an update failed because an entity didn't exist, the update will be reprocessed. However, I also think that makes it harder to reason about the effects of a change to an entity list's workflow (changing it to create entities on receipt and having it process pending submissions).
Two ideas:
entity.error
is a submission edit.Part of me thinks that it'd be nice to completely separate a change to an entity list workflow from entity updates. In other words, changing an entity list to create entities on submission receipt and processing pending submissions may create entities, but it should never update them. However, I don't know if that separation would play well with the corner case of a submission that either updates or creates entities (
create="1" update="1"
).Central version shown in version.txt
The text was updated successfully, but these errors were encountered: