Steve Freitas <sflist@ihonk.com> writes:
The trick is that I need to add any subsequent callbacks to a new deferred which I return from the function. Strangely (to me), if I try using chainDeferred() instead of returning the new deferred from step2, it fails with AlreadyCalled, which I don't yet understand, but that's fine, 'cause this seems to work well enough.
(should have finished reading ahead since you figured out some of my prior response :-)) The above may or may not be true though, since it depends on what the subsequent callbacks are supposed to do. For example, if step3 is processing of step2 results (anything step2 can return) then you want it added to your main callback chain for your first Deferred. If however, step3 is only supposed to post-process the results of the conditional path through step2 that invokes another deferrable routine, yes, the right place to hang it is on that Deferred and not the main Deferred. Oh, and not that I probably wouldn't suggest overwriting self.d with the intermediate deferreds if you could avoid it, if only because it's bound to be confusing down the road when maintaining the code. Since you should know everyone that is going to be involved in a callback chain at the point when a particular chain is being created (either your first one, or one that is created within a callback) you should be able to add callbacks to each chain as it is created. If they are generic processing in sequence that should work with any result from - see Case 2 in my prior response - depending on when you want the subsequent processing to run. -- David