mirror of
https://we.phorge.it/source/phorge.git
synced 2025-02-02 09:58:24 +01:00
No description
afd2ace0dc
Summary: Fixes T13082. When you create a revision (say, `D111`) with `Ref T222` in the body, we write a `D111 -> T222` edge ("revision 111 references task 222") and an inverse `T222 -> D111` edge ("task 222 is referenced by revision 111"). We also apply a transaction to `D111` ("alice added a task: Txxx.") and an inverse transaction to `T222` ("alice added a revision: Dxxx"). Currently, it appears that the inverse transaction can sometimes generate mail faster than `D111` actually commits its (database) transactions, so the mail says "alice added a revision: Unknown Object (Differential Revision)". See T13082 for evidence that this is true, and a reproduction case. To fix this, apply the inverse transaction (to `T222`) after we commit the main object (here, `D111`). This is tricky because when we apply transactions, the transaction editor automatically "fixes" them to be consistent with the database state. For example, if a task already has title "XYZ" and you set the title to "XYZ" (same title), we just no-op the transaction. It also fixes edge edits. The old sequence was: - Open (database) transaction. - Apply our transaction ("alice added a task"). - Apply the inverse transaction ("alice added a revision"). - Write the edges to the database. - Commit (database) transaction. Under this sequence, the inverse transaction was "correct" and didn't need to be fixed, so the fixing step didn't touch it. The new sequence is: - Open (database) transaction. - Apply our transaction ("alice added a task"). - Write the edges. - Commit (database) transaction. - Apply the inverse transaction ("alice added a revision"). Since the inverse transaction now happens after the database edge write, the fixing step detects that it's a no-op and throws it away if we do this naively. Instead, add some special cases around inverse edits to skip the correction/fixing logic, and just pass the "right" values in the first place. Test Plan: Added and removed related tasks from revisions, saw appropriate transactions render on both objects. (It's hard to be certain this completely fixes the issue since it only happened occasionally in the first place, but we can see if it happens any more on `secure`.) Reviewers: amckinley Reviewed By: amckinley Maniphest Tasks: T13082, T222 Differential Revision: https://secure.phabricator.com/D19969 |
||
|---|---|---|
| bin | ||
| conf | ||
| externals | ||
| resources | ||
| scripts | ||
| src | ||
| support | ||
| webroot | ||
| .arcconfig | ||
| .arclint | ||
| .arcunit | ||
| .editorconfig | ||
| .gitignore | ||
| LICENSE | ||
| NOTICE | ||
| README.md | ||
Phabricator is a collection of web applications which help software companies build better software.
Phabricator includes applications for:
- reviewing and auditing source code;
- hosting and browsing repositories;
- tracking bugs;
- managing projects;
- conversing with team members;
- assembling a party to venture forth;
- writing stuff down and reading it later;
- hiding stuff from coworkers; and
- also some other things.
You can learn more about the project (and find links to documentation and resources) at Phabricator.org
Phabricator is developed and maintained by Phacility.
SUPPORT RESOURCES
For resources on filing bugs, requesting features, reporting security issues, and getting other kinds of support, see Support Resources.
NO PULL REQUESTS!
We do not accept pull requests through GitHub. If you would like to contribute code, please read our Contributor's Guide.
LICENSE
Phabricator is released under the Apache 2.0 license except as otherwise noted.