Whilst trying to understand how the existing Orphan Slayer job works we put together some documentation and an activity diagram to hopefully capture the process as it works today. This should help us when implementing its successor, the Pending Transaction Consumer & Resolver.
Description
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | None | T276183 Epic: Automatically send status 800 on prior donors stopped at 600 | |||
Resolved | None | T295926 Orphan Slayer deep dive documentation |
Event Timeline
Thanks so much for your work on this, @jgleeson and @Damilare! Great stuff! :) This really helped me figure out what's going on with this code.
I understand that this is documentation about legacy code that we hope to remove soon, so probably it's not worth worrying too much about details? Once the new code is finalized, I guess we'd make a new diagram and update the doc?
Assuming that'd be the case, here are some ideas for said new diagram and updated doc:
- We could upload the diagram to the wiki and include it on the doc page, and also maybe add references numbers in the diagram to point to related parts of the text?
- Maybe include a bit more details about files or PHP classes involved, and add links to the actual code in the online repository browser?
- Maybe also add a bit more background on how things get into the pending table to begin with?
- Instructions on how to test locally.
Regarding the current doc for the soon-to-be-legacy version, here are a few very minor details I found (though not super important):
- "As well as the OrphanSlayer, other ways by which the Pending Table are": Part of a phrase may be missing here?
- "consumers are run every 3/4 minutes": I guess this means they're "run every 3 and 4 minutes respectively" (might be misunderstood to mean, "every three fourths of a minute")?
- "??" (first point of the second section): Maybe we could check this, I guess?
- In the diagram, shouldn't PendingDatabase::get_oldest() be OrphanSlayer::get_oldest() or PendingDatabase::fetchMessageByGatewayOldest() ?
- $slayer->cancel($orphan) and $adapter->cancelCreditCardPayment() have double exit arrows.
(Regarding the code for the diagram, see also T296344.)
Thanks again! :)
Thanks for digging in here and I'm glad they were useful! WRT to the points on the diagram:
Yes it should! good spot. thanks
- $slayer->cancel($orphan) and $adapter->cancelCreditCardPayment() have double exit arrows.
Do you mean $adapter->cancel($orphan) ? the extra activity path is coming from the scenario where the contribution_id set. I think you're referring to the 2 lines that carry on from those steps? If so, yeah, not sure why PlantUML does this when paths merge. I guess I can see why it might be useful but can also see that a single path would suffice! (If I've misunderstood this let me know!)
I've updated the diagram here
Let me know if you have any more feedback on the other point mentioned. If not I can move this one to done. Thanks