this is what makes sense given that:
* it's the lesser used of the to EMAIL_USE_xxx variables
* the two settings are mutually exclusive
This was simply wrong-when-introduced in 921d5bd4a3
See #86 (recent discussion of someone running into a related problem).
This commit fixes 3 related issues with the way runtime_limit was administered;
which could lead to race conditions (and hence: the wrong runtime_limit
applying at some point in time). Post-fix, the folllowing holds:
1. We use thread_locals to store this info, since there are at least 2 sources of
threaded code that touch this (snappea's workers and the django debugserver)
2. We distinguish between the "from connection settings" timeout and the
"temporarily overridden" ones, since we cannot assume
connection-initialization happens first (as per the comment in base.py)
3. We store runtime-limits per alias ('using'). Needed for [2] (each connection
may have a different moment-of-initialization, clobbering CM-set values from
the other connection) and also needed once you realize there may be
different defaults for the timeouts.
General context: I've recently started introducing the 'different runtime'
helper quite a bit more; and across connections (snappea!), which created more
and more doubts as to it actually working as advertised.
Thoughts on "using" being required. I used to think "you can reason about a
global timeout value, and the current transaction makes clear what you're
actually doing", but as per the notes above that doesn't really work.
Thoughts on reproducing:
A few thoughts/notes on reproducing problems with race conditions. Basic note:
that's always hairy. So in the end I settled on a solution that's hopefully
easy to reason about, even if it's verbose.
When I started work on this commit, I focussed on thread-safety; "proving the
problem" consisted of F5/^R on a web page with 2 context managers with different
timeouts, hoping to show that the stack unrolling didn't work properly.
However, during those "tests" I noticed quite a few resets-to-5s (from the
connection defaults), which prompted fix [2] from above.
Given what immediate_semaphore _is_, the principled need for this is obvious.
In practice, this wasn't needed yet (immediate_atomic is not used for
any non-default DB). But better fix it before we do decide on that.
it was reporting the actual sqlite get-write-lock timings, but since the
introduction of the immediate_semaphore those were 'basically never' blocking
since all the blocking was done in the semaphore (ignoring cross
gunicorn/snappea details)
like so:
```
$ sentry-cli --url http://bugsink:8000/ login
This helps you signing in your sentry-cli with an authentication token.
If you do not yet have a token ready we can bring up a browser for you
to create a token now.
Sentry server: bugsink
Open browser now? [y/n] y
```
See https://github.com/getsentry/sentry/issues/82078
I did not do any research into actual timings (i.e. whether there really is a
need to pull this out of the request/response loop) but it seems somewhat
prudent. Because Sentry also does this (and does it at this point), the whole
thing of matching Sentry's interface is not being complicated by it (if
anything: the contrary).
