Attempt to recover from race conditions for FileDiff migration.
Review Request #8245 — Created June 14, 2016 and submitted — Latest diff uploaded
We've been seeing an issue where users have hit errors during the
process of diff migration where a referencedLegacyFileDiffData
referenced by aFileDiff
is missing in the database. These are in
requests that follow a successful migration, pointing to a potential
race condition where one request migrated a diff and the other then
tried with stale data.If the migration can't find the
LegacyFileDiffData
associated with a
request as part of the migration process, it will instead try to reload
the newRawFileDiffData
IDs from the database and inject them into
the FileDiffData. It will sanity-check whether there are proper values
to find, erroring out if not.It also fixes the save calls for
FileDiff
s. We had a bunch of
save(update_fields=[...])
calls sprinkled around, but these weren't
doing anything special, since we didn't propagateupdate_fields
to the
parent. We now do this in an effort to prevent another case where
migrated IDs could be overridden.
Wrote a unit test that exhibited the same problem that we've seen in
the logs. It passes with this fix.All other unit tests pass as well.
Simulated missing database entries with keys still set. Saw the error
information. (Callers still fail, since there's no diff to get, but
it's clear something went wrong, and IDs are provided.)