I'm continuing to have some stuck deferreds - deferredlists probably.

I had that graphviz/twisted graphing thing working for some test code, but upon applying it to some deferreds that're getting stuck in some production code, I didn't get the same pleasing output - not entirely surprising.  Part of the issue is that some of the deferreds have already disappeared (which in a way is a good thing - less to sift through to find what's left), and part of the matter is I believe there are some custom __repr__'s in the code that are causing my graph code to discover violated assumptions.

Anyway, what I got, greatly truncated on the right, looks like:
  Deferred_at_0x46edcf8 -> bound_method_DeferredList._cbDeferred_of_DeferredList_at_0x46ed3b0_current_result
  Deferred_at_0x46edcf8 -> bound_method_DeferredList._cbDeferred_of_DeferredList_at_0x46ed3b0_current_result

To the right of those two lines appear to be a huge dictionary dump - and I do mean huge.

Grep'ing through the code, I see no "current.result" matches.  There is however a "current\.result" in the twisted code.

...so... I suppose I'm looking for a deferred (list) at a specific id(), though that's a little fiddly to catch.

Can anyone think of other ways of getting to the bottom of this?  Perhaps some field in a deferred or deferredList I can introspect to get better specifics?

Is monkey patching an identifier of some sort into each deferred reasonable?  The intent would be to make it easier to match up the lingering DeferredLists with the place they're created.

TIA!