Skip to content

Request State Middleware #115

Closed
Closed
@k-macmillan

Description

@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

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.

Metadata

Metadata

Assignees

Labels

Dev ReviewedReviewed by Tech LeadNotifyBoard triggerOff-trackTaking beyond the expected point valuePM ReviewedReviewed by Product ManagerQA ReviewedReviewed by Quality Assurance

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions