Toxic Exposure 1.0: Revisit retryable and non-retryable errors

[aurora-a-k-a-lightning]

As an engineer I need to know how our service should respond to Lighthouse errors so I know what to do in response.

Review these notes from August 1st, the "Retryable" and "Non-retryable" sections.

• add to Retryable:
  • HTTP 401
  • HTTP 429 - hit the rate limit
  • HTTP 499 - 504 - usually indicates something wrong w upstream service
  • add to non-Retryable
  • HTTP 404 - bad ICN, resource doesn't exist
  • HTTP 413 - payload is too large (unlikely)
• Conditionally Retryable
  • HTTP 422: if there is no pointer attribute in the error. This indicates there was a problem with an upstream service that LH can probably retry. Retry for our usual 24 hours, then send down the backup path if

Tasks

• implement logic in submitForm526Job handle errors method
• Communicate changes to Carbs, ask for risks/challenges
• Put behind Toxic Exposure feature flag

Additional Information

We share a client id with the claims status tool We're also adding the polling job, using the same endpoint Should do this before 5% Canary

[christinec-fftc]

Ask from Emily in planning today - can we revisit the Veteran experience when these various errors occur? We can use this opportunity just for FE discovery and file any new tickets (design or FE implementation) as needed.

Happy to pair on this!

[christinec-fftc]

related discussion on current UX (thread)

[mayacarrolluxa6]

@aurora-a-k-a-lightning I took a pass at designing a conditionally retry able error page.