<br>I&#39;m continuing to have some stuck deferreds - deferredlists probably.<br><br><div class="gmail_quote"><div>I had that graphviz/twisted graphing thing working for some test code, but upon applying it to some deferreds that&#39;re getting stuck in some production code, I didn&#39;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&#39;s left), and part of the matter is I believe there are some custom __repr__&#39;s in the code that are causing my graph code to discover violated assumptions.<br>
<br>Anyway, what I got, greatly truncated on the right, looks like:<br>  Deferred_at_0x46edcf8 -&gt; bound_method_DeferredList._cbDeferred_of_DeferredList_at_0x46ed3b0_current_result<br>  Deferred_at_0x46edcf8 -&gt; bound_method_DeferredList._cbDeferred_of_DeferredList_at_0x46ed3b0_current_result<br>
</div></div><br>To the right of those two lines appear to be a huge dictionary dump - and I do mean huge.<br><br>Grep&#39;ing through the code, I see no &quot;current.result&quot; matches.  There is however a &quot;current\.result&quot; in the twisted code.<br>
<br>...so... I suppose I&#39;m looking for a deferred (list) at a specific id(), though that&#39;s a little fiddly to catch.<br><br>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?<br>
<br>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&#39;re created.<br><br>TIA!<br><br><br>