-
Notifications
You must be signed in to change notification settings - Fork 23
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM but mypy is failing badly. I suspect is partially because of comment below, and because of a lot of calls are made using app.state.gstate
, which will likely confuse the static checker because, I suspect, the type of app.state
is not known.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, commit is missing the DCO.
FYI I haven't done a deployment to verify everything still works since rebasing this. |
jenkins run tumbleweed |
jenkins run leap |
I guess you saw these multiple traces:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks really great, but there's a few things that are mostly nits, a few other things we can change in a follow-up PR, and one thing I'm pretty sure it's a hard bug.
This refactor instantiates Tickers (ie long running sub processes that persist across requests+sessions) as part of the app. It stores them inside FastAPI's `app.state`, which in turn is available on FastAPI's `Request` object. Signed-off-by: Joshua Hesketh <josh@nitrotech.org>
This change also reduces usage of mocks which can cause issues between isolated tests. Signed-off-by: Joshua Hesketh <josh@nitrotech.org>
Signed-off-by: Joshua Hesketh <josh@nitrotech.org>
Signed-off-by: Joao Eduardo Luis <joao@suse.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pushed a patch that fixes unresolved issues.
jenkins run tumbleweed |
This refactor instantiates Tickers (ie long running sub processes that
persist across requests+sessions) as part of the app. It stores them
inside FastAPI's
app.state
, which in turn is available on FastAPI'sRequest
object.I could not find the most "FastAPI way" of doing this. From my reading, the way we were handling state with module level globals is generally the approach that FastAPI takes. This has some difficult draw backs with mocking and testing, not to mention potential complications on instantiating multiple redundant (or even conflicting) instances, and the general developer confusion about what they are accessing. There is some good discussion on it here: tiangolo/fastapi#81
The solution, as describe in the commit above, is to create all the Tickers ourselves and register them in
app.state
. This will make it trivial to swap them out for fake Tickers in our testing as we can build differentapp
's.Follow up:
Closes: #276
Closes: #282