Fix some bugs when creating attachments for FileDiffs.
Review Request #13546 — Created Feb. 16, 2024 and submitted
There are two more bugs I ran into when creating attachments for a
FileDiff:
When creating a FileAttachment for a given FileDiff, we were creating
a draft for the review request. Diff-specific attachments aren't part
of the usual draft flow for the review request, so this isn't
necessary.Review requests and review request drafts both have relations to file
attachments. When we create a new attachment for a FileDiff, we were
correctly associating it with the review request, but we were not
associating it with the draft. This meant that if there was a draft
(as there often is when posting a new diff), publishing that draft
would erase the relation to the ReviewRequest.These objects also have a RelationCounterField for the FileAttachment
relation, which is used when computing things like the ETag to
shortcut if there are no attachments. This change also makes sure
we're saving those fields when adding new attachments.
- Ran unit tests.
- Posted changes including binary files and no longer saw extra drafts.
- Verified that the file_attachment_counts field was set correctly.
- Published a diff and saw that my file attachments didn't disappear and
file_attachment_counts didn't zero out.
-
-
I take it this is the last paragraph in your description.
RelationCounterField
changes are atomic, made on the table using anUPDATE .. WHERE ..
, and then stored back in the local model. They don't need to be saved.If saving fixes this, we have a bug somewhere where we're overwriting state (which this ends up doing as well), and we'll need to get to the root of that bug.
-