Take the 2-minute tour ×

I'm looking for ideas on how to make RX more easily debuggable. It can be so very difficult to find the point of failure when a source is passed through combiners and throttles and publishes and such.

So far I've been doing similar things to what I do with complicated Enumerable chains - inserting Do() for tracing, adding a "name" field to an anonymous type part way through, grabbing stack traces sometimes.. But we have perhaps hundreds of producers and maybe thousands of consumers in our system and it's getting very hard to isolate problems.

What kinds of tricks do you have for debugging your RX usage?

share|improve this question
Great question. I'm always struggling to debug my Rx code. –  Jim Nov 22 '11 at 10:01
I strongly disagree with this question being casually closed by casperOne. I am looking for expertise in a very specific technology. This question will not likely result in "opinion, debate, arguments, polling, or extended discussion". –  Scott Bilas Nov 29 '11 at 17:48
Not constructive? Maybe the question is not quite specific enough, but it's a highly valuable question. Oh well, back to the "why doesn't this code compile" questions. –  Niall Connaughton Feb 3 '12 at 10:09
Voted to reopen –  Tom Bushell Jun 20 at 22:05
While this question may lead to some discussion, it seems like a reasonable question. The asker mentions specific debugging techniques that he tried and outlines why they aren't sufficient in specific circumstances. One would hope answers to this question would enumerate additional proven debugging techniques, wich would benefit readers of this site. Voting to re-open. @Scott Bilas: I think it would improve the question if you could clarify why in this your specific set of circumstances the techniques already tried make it "very hard to isolate problems". –  njuffa Jun 20 at 22:47
add comment

2 Answers

I think a constructive discussion on this topic has been had on the Rx Forums in 2009.

Instead of adding adhoc Do operators into your queries, you would add a custom Log/Trace operator. This operator would capture the Subscription, Disposal, OnNext, OnError and OnCompleted events. Depending on your implementation it could just write to the console, use your favorite Logger library or even create ETW events for OS and Visual Studio integration.

public static class ObservableTrace
    public static IObservable<TSource> Trace<TSource>(this IObservable<TSource> source, string name)
        int id = 0;
        return Observable.Create<TSource>(observer => 
            int id1 = ++id;
            Action<string, object> trace = (m, v) => Debug.WriteLine("{0}{1}: {2}({3})", name, id1, m, v);
            trace("Subscribe", "");
            IDisposable disposable = source.Subscribe(
                v => { trace("OnNext", v); observer.OnNext(v); },
                e => { trace("OnError", ""); observer.OnError(e); },
                () => { trace("OnCompleted", ""); observer.OnCompleted(); });
            return () => { trace("Dispose", ""); disposable.Dispose(); };
share|improve this answer
add comment

One important trick for catching Rx bugs is to retry debugging with first-chance exceptions enabled, this makes it way more likely that you'll get a real exception message instead of a rethrown one:

share|improve this answer
I'm always surprised when people don't run with exceptions set to catch first-chance. It's like flying blind. –  Scott Bilas Nov 22 '11 at 19:20
Rx are often time-dependent so stepping through is often not an option. Traces are used in time-sensitive debugging. –  Vadim Chekan Jan 8 at 4:25
add comment

Your Answer


