Well what you have here is fairly different from what I suggested in the Jira.  What I suggested was to move all the 'afterCompletion' logic into a separate method that we could either call immediately (isRegistrationThread) or delayed (!isRegistrationThread).

As your method stands now, no, I do not think the best option is to simply call back into afterCompletion since you'd be incurring the perf hit of thread checking the second time too (this is precisely the reason I broke the actual after-completion handling out into a separate method).  In fact, given how non-performant the current Thread resolution can be we also might want to have a flag for environments that handle this better to opt out of this thread checking.