Request State Middleware

[k-macmillan]

User Story - Business Need

We need to store state data for a given request. That may be a request_id, a service_id, or any other number of things. This stored data is particular to the request, and should persist for all tasks related to it. Consider mypy early in the process. We will start with a request_id (the notification id).

• Sync with Kyle when ticket is picked up.
• Ticket is understood, and QA has been contacted (if the ticket has a QA label).

User Story(ies)

As a VA Notify dev
I want To store request data
So that I can access necessary context

Additional Info and Resources

• Python docs on contextvars
• Passing context to coroutines

Acceptance Criteria

• Bear in mind SOLID principles - This is a good use case for ISP/DIP
• Repeatable method for establishing context
• request_id is available globally for that request
• state is cleaned up
• This work is added to the sprint review slide deck (key win bullet point and demo slide)

QA Considerations

Potential Dependencies

Out of Scope

Really testing this will involve hammering it with something like locust to ensure the context isn't jumping around. Trivial tests at human speeds are not sufficient. That exceeds the scope of this ticket.

[mchlwellman]

I'm integrating starlette-context into the app. There's a plugin architecture which I'm working through, the builtin request id plugin seems to be case-sensitive, so I added a custom one but it's not working right.

[mchlwellman]

I have the AC done for this ticket, but the easiest way to test and show it's working is to log, and getting loguru to log context without developer input has been complicated. It's easy to log with context per statement, the issue is in getting the app logger to do it by default.