Breakpoints trip timeout with a confusing stack track in rx.run

[GregRos]

First of all, great work with the library! Coming from rxjs and similar tools, I feel right at home. I've actually built something kind of similar called doddle.

However, I did encounter an issue with the library -- having a timeout on rx.run by default results in some pretty confusing behavior when debugging.

A developer can easily miss the timeout parameter, like I did, and if they do and they set a breakpoint, they will be treated to a long and confusing stack trace:

It's even worse that it doesn't happen all the time, and it seems to depend on where I put the breakpoint, creating an erratic experience that's all the more confusing.

Here are some suggestions to improve things.

Avoid timeouts

First, try to avoid using timeouts unless the user explicitly uses a time-based operator. If that happens, the user asked for it so they know what's going to happen.

This might cause code to hang in some cases instead. However, I feel this is part and parcel of working using async constructs and is only to be expected. At the very least, the behavior will be consistent, and won't change based on whether the code is being debugged.

One way to deal with it is to emit warnings.

Increase the length of the timeout

Right now, the timeout seems to be at 2 seconds by default. This seems far too short and likely to be tripped by network latency and I/O heavy pipelines.

You should probably increase it to something like 2 minutes if the intent is to avoid the job hanging. That will cause noticeable delays, but you actually want the timeout to be extremely noticeable if it happens.

Make it clear when a timeout is caused by aioreactive

When working with async code, multiple parts of your code will probably have their own timeouts, such as HTTP requests.

This means that a generic timeout error makes the source of the timeout confusing. To fix this, it's better for the error to explicitly convey the source of the timeout.

• The name of the package
• The operator or construct that caused the timeout
• If it's a default mechanism, what can be done to deactivate it.

If possible, the last entry in the stack trace should point to library code.