<br>I'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'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.<br>
<br>Anyway, what I got, greatly truncated on the right, looks like:<br> Deferred_at_0x46edcf8 -> bound_method_DeferredList._cbDeferred_of_DeferredList_at_0x46ed3b0_current_result<br> Deferred_at_0x46edcf8 -> 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'ing through the code, I see no "current.result" matches. There is however a "current\.result" in the twisted code.<br>
<br>...so... I suppose I'm looking for a deferred (list) at a specific id(), though that'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're created.<br><br>TIA!<br><br><br>