Clear invalidated flag when prompt is re-saved with unchanged data

[rmcew]

Summary

• When a prompt is externally invalidated (via invalidUponChange) and the user re-saves it without changing data, equal() returns true and setRequirementPromptsValid is never called — leaving the prompt permanently stuck as invalidated
• Adds a setRequirementPromptsValid([prompt.key]) call before the equal() check so any successful save clears the invalidated flag

Test plan

• Answer prompts A and B, where A has invalidUponChange targeting B
• Go back and change A's answer — B should become invalidated
• Navigate to B and click Continue without changing anything — B should no longer be invalidated and navigation should proceed

Ref: txstate-etc/va-certification#165

[wickning1]

My concern is accidental autosaves in the reviewer UI. We try to prevent them but it's a very fragile thing. If we do this we may need to force invalidated reviewer prompts behind an edit modal instead of having their form be inline.

[rmcew]

Ah. I haven't gotten to the reviewer side yet so I didn't think of that wrinkle

Whatever solution you think is appropriate is fine with me, it's just currently a bug causing issues downstream

[saultminer]

@wickning1 We discussed some time ago, but I thought this was per design.

Reviewer to applicant invalidation:
We didn't want a reviewer to say 'That not a driver's license', invalidate the applicants drivers license input prompt, return app to the applicant, then have the applicant go right back and just click continue again without modifying the data. We wanted a change or a confirmation toggle that the info has been reviewed and is correct before nav (save)

Applicant to reviewer:
Reviewer side we had the idea that if a change to an applicant prompt then invalidated a prompt on the reviewer side (they updated the drivers license details so now reviewer needs to check again), we would show some kind of inline confirmation that they had to confirm data is still correct after applicant prompt changed.

Both directions I'm pretty sure you wanted a change of data to confirm, and not just gloss over. Applicant change to reviewer is most risky as if we don't require a data mod (or extra data) then a reviewer could save without ever re-validating applicant details.

[wickning1]

That's true. @rmcew, help me understand the original ticket. Why was veteran disabled status marked as invalidated? Generally that feature is for reviewers telling the applicant they made a mistake.

[rmcew]

This is applicant-to-applicant. Here, we are changing the benefit situation, which changes which downstream prompts are available. To do that, we feed the prompts to invalidUponChange. The problem occurs when the invalidated prompt's stored data hasn't been cleared. The user re-saves identical data, equal() returns true, and the invalidated flag is never cleared.
Uploading Screen Recording 2026-05-13 at 5.42.56 PM.mov…

[wickning1]

Ok, I took a look at the situation in VA Cert. In your case I think the better solution would be to include the list of documents they are confirming they've seen in the payload. Something like

<SubArray path="documents">{#each}<FieldHidden path="" value={doc.name}/>{/each}</SubArray>

That solves this problem without needing invalidUponChange at all - you can code the requirement's resolve function to demand that the list of documents they confirmed matches the situation they're in. It also creates a more bulletproof record for posterity that the applicant saw the correct list before they proceeded.

There may still be a distinction to be made between "this prompt needs review because another prompt changed" (let's call it "checkAgain") and "this prompt is flatly incorrect and must be changed based on the answer to another prompt" (let's call it "mustCorrect").

Reviewer-to-applicant invalidations are usually mustCorrect - you were supposed to upload a driver license, the reviewer says you uploaded something else, you MUST try again. Applicant-to-reviewer will usually be checkAgain - I have uploaded a new document, hopefully it's a driver license, please review it but you can say the answer is still No.

I had hoped that we could limit checkAgain to the reviewer UI, but I can see that I could be wrong about that.

Perhaps we need to find some way to let the downstream developer declare the difference between checkAgain and mustCorrect. In the checkAgain situation we could allow a save to go through, in mustCorrect we demand a change.