Conversation
We have seen some errors where the enrollment passed to the IPP verify_info_presenter is nil. This guards against that error, though it is currently unclear how the enrollment could be nil here. This may result in kicking the error further down the stack, but that may give a clue as to where/how this is happening. changelog: Bug Fixes, Passports, Guard against a nil enrollment.
solipet
requested review from
AShukla-GSA,
Mawar2,
WilliamBirdsall,
amirbey,
shanechesnutt-ft and
theabrad
|
|
||
| def passport_flow? | ||
| @enrollment.passport_book? | ||
| @enrollment&.passport_book? |
There was a problem hiding this comment.
It feels dangerous to allow a nil enrollment here since it in theory can't be. Can we look further to understand the cause better?
There was a problem hiding this comment.
Yes, thanks for the pushback!
Shane and I paired yesterday afternoon and managed to identify the uuid of the user that triggered this and examine their activity. Our best guess is that they started IPP, then when they failed IV they appear to have gone back to the Welcome page, but then returned to the verify info page, either via browser back/forward buttons or maybe a saved url.
I've updated the title and summary to reflect the new changes.
the establishing enrollment exists. Co-authored-by: Shane Chesnutt <shane.chesnutt@gsa.gov>
Mawar2
left a comment
Mawar2
left a comment
There was a problem hiding this comment.
Looks good - the preconditions approach is much cleaner than defensive nil checks. Nice work tracking down the root cause.
4 participants
🎫 Ticket
Link to the relevant ticket:
LG-16288
🛠 Summary of changes
We have seen some errors where the enrollment passed to the IPP verify_info_presenter is nil.
In #11939 we started cancelling enrollments upon visiting the Welcome page which is how, we believe, the user ended up with a nil enrollment. That change doesn't align with the work we did previously on Team Ada with the FlowPolicy which intended for controllers in the idv flow to define a StepInfo that includes preconditions and a proc to clean up (undo) the action. The FlowPolicy work was intentionally done to allow users to use the back/forward buttons at will.
This PR updates the IPP controllers preconditions to ensure that if an establishing enrollment is not present the user will be redirected back in the flow to the proper place.