With the migration to Lighthouse's API endpoint for submission, instead of receiving information during the submission process, the system will need to "poll" for information about the submission status to display to the user.
The goal is to gain an understanding as to how we can re-route the current workflow to handle not getting a claim_id back.
This will most likely also involve the frontend.
Tasks
[ ] Document the following:
[ ] in app/sidekiq/evss/disability_compensation_form/submit_form526.rb around line 112, we hooked in the call to Lighthouse to perform the actual submission - that will work fine. However, we will not be getting back a response with the claim_idto save to the Form526Submission record in the database. According to Lighthouse, we will get a response back with a "Lighthouse ID" (yet-another-id) that will have to be used to poll to get the status and claim id for the submission. The question: How can we "re-route" this response so that the job does not fail when it does not get an ID back?
[ ] Do we need to save off the "Lighthouse ID" for further processing and polling? (aurora's guess is "yes").
[ ] If so, how do we write a migration to add this column to the Form526Submission table?
[ ] How does the frontend use the information from the job result? Will this have to change?
Acceptance Criteria
[ ] Documented understanding of how the submission job can be re-routed to not fail when attempting to retrieve and save a VBMS claim_id to the Form526Submission record.
Added information to this document
How to configure this issue
[ ] Attached to a Milestone (when will this be completed?)
[ ] Attached to an Epic (what body of work is this a part of?)
[ ] Labeled with Team (product support, analytics-insights, operations, service-design, Console-Services, tools-fe)
[ ] Labeled with Practice Area (backend, frontend, devops, design, research, product, ia, qa, analytics, contact center, research, accessibility, content)
[ ] Labeled with Type (bug, request, discovery, documentation, etc.)
Issue Description
With the migration to Lighthouse's API endpoint for submission, instead of receiving information during the submission process, the system will need to "poll" for information about the submission status to display to the user.
The goal is to gain an understanding as to how we can re-route the current workflow to handle not getting a
claim_id
back.This will most likely also involve the frontend.
Tasks
app/sidekiq/evss/disability_compensation_form/submit_form526.rb
around line 112, we hooked in the call to Lighthouse to perform the actual submission - that will work fine. However, we will not be getting back a response with theclaim_id
to save to the Form526Submission record in the database. According to Lighthouse, we will get a response back with a "Lighthouse ID" (yet-another-id) that will have to be used to poll to get the status and claim id for the submission. The question: How can we "re-route" this response so that the job does not fail when it does not get an ID back?Acceptance Criteria
[ ] Documented understanding of how the submission job can be re-routed to not fail when attempting to retrieve and save a VBMS
claim_id
to the Form526Submission record. Added information to this documentHow to configure this issue
product support
,analytics-insights
,operations
,service-design
,Console-Services
,tools-fe
)backend
,frontend
,devops
,design
,research
,product
,ia
,qa
,analytics
,contact center
,research
,accessibility
,content
)bug
,request
,discovery
,documentation
, etc.)