Page MenuHomePhabricator

Move "update related object after commit" to a separate worker in the task queue

Authored by epriestley on Apr 22 2019, 10:51 PM.



Depends on D20462. Ref T13276. Currently, the "Message" parser also updates related tasks and revisions when a commit is published.

For PHI1165, which ran into a race with message parsing, I originally believed we needed to separate this logic and lock + yield to avoid the race. D20462 provides what is probably a better approach for avoiding the race.

Still, I think separating these "update related revisions" and "updated related tasks" chunks into separate workers is a net improvement. There may still be some value in doing lock + yield in the future to deal with other issues, and when we occasionally run into problems with pulling a diff out of the repository to update the revision (usually because the diff is too big) this isolates the problem better and allows the commit to import.

I think the only thing to watch out for here is that Herald may now run before the revision and commit are attached to one another. This is fine for all current Herald rules, we just need to be mindful in implementing new rules.

Test Plan

Used bin/repository reparse --message on various commits, including commits that close revisions and close tasks.

Diff Detail

rP Phabricator
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

epriestley created this revision.Apr 22 2019, 10:51 PM
epriestley requested review of this revision.Apr 22 2019, 10:52 PM
epriestley added inline comments.Apr 22 2019, 10:53 PM

This works with workers which queue other workers. The old code was just a very old version of the more modern "run in process" flag.

amckinley accepted this revision.Apr 24 2019, 12:32 AM
amckinley added inline comments.

Whoa, that's a new one.

This revision is now accepted and ready to land.Apr 24 2019, 12:32 AM
epriestley added inline comments.Apr 24 2019, 1:02 PM

Haha, yeah -- I think there's a comment somewhere else in the internals, but basically we don't want Fixes T123 to also generate an "alice mentioned Txxx on..." transaction since it's redundant.

This revision was automatically updated to reflect the committed changes.