Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request State Middleware #115

Open
6 tasks
k-macmillan opened this issue Dec 30, 2024 · 0 comments
Open
6 tasks

Request State Middleware #115

k-macmillan opened this issue Dec 30, 2024 · 0 comments
Labels
Dev Reviewed Reviewed by Tech Lead Notify Board trigger PM Reviewed Reviewed by Product Manager QA Reviewed Reviewed by Quality Assurance

Comments

@k-macmillan
Copy link
Member

k-macmillan commented Dec 30, 2024

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).

  • 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

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.

@k-macmillan k-macmillan added Dev Reviewed Reviewed by Tech Lead Notify Board trigger labels Dec 30, 2024
@cris-oddball cris-oddball added the QA Reviewed Reviewed by Quality Assurance label Jan 3, 2025
@kbelikova-oddball kbelikova-oddball added PM Reviewed Reviewed by Product Manager Ready for Refinement labels Jan 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Dev Reviewed Reviewed by Tech Lead Notify Board trigger PM Reviewed Reviewed by Product Manager QA Reviewed Reviewed by Quality Assurance
Projects
None yet
Development

No branches or pull requests

4 participants