PYIC-7189: SPIKE repeat CRI callbacks

[thebauSoftwire]

Proposed changes

What changed

• Adding lock timestamp to CriOauthSessionItem (this expires after 5 minutes) if the callback has not yet been processed.
  Processing continues after this and resulting journey saved to CriOauthSessionItem
• If record is locked:
  • Previous callback has finished processing: return journey saved onto CriOauthSessionItem
  • Previous callback still processing: return attempt-recovery page. If previous callback has finished, we recover the user state (e.g. the success screen) otherwise they get redirected back to the previous state (CRI) and have to go through the CRI again.

I also experimented with trying to check the CriOauthSessionItem again in ProcessJourneyEvent if the attempt-recovery event was given AND the current state is a CRI state so that we can check here again if the processing was complete on that oauthState. This could help with lengthening the window to process the callback. However, if still not complete by then, the user would have to go through the CRI again.

I also thought about trying to return the user back to the attempt-recovery screen if the processing wasn't finished (at the point where the user selects continue from the attempt-recovery screen) but this added quite a bit more complexity which I thought wasn't worth it if the CRIs mostly affected are the DCMAW (not really used anymore with V2 app) and CIC (fairly quick and easy to go through) CRIs.

Testing Results:

Scenario	Outcome
Request has finished processing once the user selects continue from the attempt recovery screen	Recovers to intended state e.g. successful VC recovers to page-dcmaw-success
Request is still processing when the user continues from attempt-recovery screen	Recovers at DCMAW state so user would have to go through CRI again
More than 2 repeated callbacks First request has finished processing once user continues from attempt-recovery	Recovers to intended state e.g. dcmaw-success page given successful VC
More than 2 repeated callbacks First request is still processing once user continues from attempt-recovery	Recovers to CRI state (DCMAW) and user has to go through CRI again
More than 2 repeat callbacksRecord lock expires before the user selects to continue from attempt-recovery	Recovers to dcmaw-success page
First callback is successfulSecond callback is server_error	Recovers to dcmaw-success page
First callback is successfulSecond callback is access_denied	Recovers to dcmaw-success page
First callback is server_errorSecond callback is successful	Recovers to pyi-technical screen
First callback is access_deniedSecond callback is successful	Recovers to multiple-doc-check page
Pressing back after callback then making another callback	Recovers to dcmaw-success page
Regression check:Single callback results in correct state	Results in dcmaw-success page

Why did it change

• When a user makes repeat CRI callbacks, their journey may error e.g. if the second callback is an error which will be processed faster than the first request or the second request fails with invalid oauth state as the auth code was used twice. Hopefully, this ensures that only one request is dealt with at a time and returns the result from the previous request without having to process subsequent ones.

Impact:
From 30/06/2025-28/07/2025, the number of repeat callbacks by CRI:

Issue tracking

• PYIC-7189

Checklists

• API/ unit/ contract tests have been written/ updated
• No risk of exposure: PII, credentials, etc through logs/ code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
90.7% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud