Anything related to the abstraction "transactions" in the Phabricator code stack. These bad boys are what individual actions like comments are composed of within a given Phabricator application. In theory anyway...
Jul 21 2021
The stalled transactions on this host published after I deployed the update.
This happens when a recipient list includes an Owners package which has been destroyed. Specifically, we'll exit this section of PhabricatorMetaMTAMemberQuery with out the PHID in $package_map, and then fail to return it:
Mar 27 2021
Jul 21 2020
May 4 2020
Nov 8 2019
Oct 17 2019
Jun 22 2019
Jun 20 2019
Jun 19 2019
I think that might be everything? Not entirely sure, but haven't seen any more since the last deploy.
Jun 17 2019
I deployed that last round of things to secure. Not totally confident I got everything, but hopefully we're in better shape now.
uhoh looks like I'm a dum dum
This is doing somewhat better now, but I've still seen:
May 30 2019
D20563 probably fixes mail. I don't think (?) it will fix notifications but haven't hunted that down yet.
May 23 2019
May 22 2019
Per D20533, the major query this UI uses is currently unkeyed (no dateCreated key on transaction tables).
May 21 2019
May 20 2019
May 9 2019
My expectation is that this is effectively resolved by T13277. Since "Autoclose" is no longer a separate permission from "Publish", commits should now always mention + close or never mention + close.
Apr 22 2019
Apr 15 2019
Feb 26 2019
Feb 25 2019
Currently, project tag changes and subscriber changes don't expose data in "transaction.search" because there's no "obviously correct" way to represent these changes in a future-proof way.
To my surprise, it also seems the method does not output any project tag changes that happened on a task?
Feb 24 2019
Thanks for the quick reply!
Haven't played with webhooks yet so I did not know/realize it's transaction PHIDs only - "PHID" sounded generic enough that I incorrectly expected any kinds of PHIDs to be accepted as input. So this task is somewhere between either "clarify documentation that only transaction PHIDs are supported" or a "support other PHIDs" low-prio enhancement request.
Feb 23 2019
The phids constraints matches transactions with specific PHIDs (PHID-XACT-...). Usually, you'll have a list of transaction PHIDs when you're responding to a webhook callback, so the phids constraint is most useful for webhooks.
Feb 20 2019
Probably a good idea, but not worth keeping a task around for.
Feb 15 2019
I believe we haven't seen more of this in two years, and "make the worker always exit in less than 2 hours" is a more-or-less reasonable remedy. Getting one extra email every two hours also isn't a huge problem even if we do get this wrong.
Jan 21 2019
I believe D19969 has now fixed this, although I'm not entirely certain, since it was never reliably reproducible in production so there's no way to really test or verify it.
Jan 14 2019
This isn't trivial to resolve. The inverse transaction goes through standard "old value / new value" logic, so if we just move the entire "apply inverse transactions" block to later on, the transactions automatically no-op themselves: they do nothing by the time we apply them.