Page MenuHomePhabricator

Orphan Slayer deep dive documentation
Closed, ResolvedPublic


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.

Documentation: here
Diagram: here

Event Timeline

jgleeson updated the task description. (Show Details)
jgleeson moved this task from Backlog to Review on the Fundraising Sprint Visual C Saw board.
XenoRyet set Final Story Points to 8.
DStrine triaged this task as Medium priority.Dec 3 2021, 5:21 PM

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:

  • In the diagram, shouldn't PendingDatabase::get_oldest() be OrphanSlayer::get_oldest() or PendingDatabase::fetchMessageByGatewayOldest() ?

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

+2 for the updated doc and diagram! Thanks so much @Damilare and @jgleeson!!