resolution_fixed type_defect | by rjsparks@nostrum.com
Right now, the POST processor for review submissions looks to see if there's a file on disk matching the file it thinks it wants to write. If it finds one, it starts iterating through range(1,100) adding a -%d suffix to find a filename that isn't yet taken.
That code needs to be removed.
It is holdover from early concerns about collisions in filenames that were more likely before we arrived on the filename convention we currently have. The opportunity for collision now is vanishingly small (it would require two people with the same last name to complete the same type of review for the same version of the same document on the same day).
Having it is causing unintended trouble. If a reviewer accidentally submits twice in relatively quick succession, the view will assume the second submission is a collision. The race through the rest of the view will end up with one of the documents being properly plumbed into the review models, and the other left dangling.
Instead, when such a collision is detected, the view should simply return an error without attempting to change the review or document objects.
Issue migrated from trac:3092 at 2022-03-04 08:02:01 +0000
resolution_fixedtype_defect| by rjsparks@nostrum.comRight now, the POST processor for review submissions looks to see if there's a file on disk matching the file it thinks it wants to write. If it finds one, it starts iterating through range(1,100) adding a -%d suffix to find a filename that isn't yet taken.
That code needs to be removed.
It is holdover from early concerns about collisions in filenames that were more likely before we arrived on the filename convention we currently have. The opportunity for collision now is vanishingly small (it would require two people with the same last name to complete the same type of review for the same version of the same document on the same day).
Having it is causing unintended trouble. If a reviewer accidentally submits twice in relatively quick succession, the view will assume the second submission is a collision. The race through the rest of the view will end up with one of the documents being properly plumbed into the review models, and the other left dangling.
Instead, when such a collision is detected, the view should simply return an error without attempting to change the review or document objects.
Issue migrated from trac:3092 at 2022-03-04 08:02:01 +0000