QuestionnaireForm prematurely clears dirty state, disabling unsaved changes guard on failed submission

[anusha19murthy]

Describe the bug

QuestionnaireForm disables the unsaved changes navigation guard at the beginning of handleSubmit by calling setIsDirty(false) before validation and before async submission completes.

If client-side validation fails or server-side submission fails, the navigation guard remains disabled. Users can navigate away without any warning, resulting in silent loss of entered clinical data.

---

To Reproduce

1. Open any encounter and start filling a questionnaire (e.g., vitals, daily round, assessment).
2. Enter data in multiple fields.
3. Leave at least one required field empty.
4. Click "Submit".
5. A validation error appears.
6. Without correcting the error, click browser back or navigate to another page.
7. Observe: Navigation proceeds with no "unsaved changes" prompt and all entered data is lost.

Alternative scenario:

1. Fill the form completely.
2. Click "Submit".
3. Server returns a validation error (e.g., constraint violation).
4. Navigate away.
5. Observe: No navigation guard warning appears; data is lost.

---

Expected behavior

The navigation guard (useNavigationPrompt) should remain active until the form is successfully submitted.

Users should receive an "unsaved changes" warning if:

• Client-side validation fails, or
• Server-side submission fails.

setIsDirty(false) should only execute after confirmed successful submission.

---

Screenshots

Not applicable — behavior occurs during normal navigation after submit attempt.

---

Desktop (please complete the following information):

• OS: Windows 11
• Browser: Chrome
• Version: Latest stable

---

Smartphone (please complete the following information):

• Device: Not tested
• OS: Not tested
• Browser: Not tested
• Version: Not tested

---

Additional context

setIsDirty(false) is currently called at the top of handleSubmit before validation logic and before submitBatch resolves.

The navigation guard is defined as:
Because isDirty is cleared prematurely, the guard is disabled even if submission does not succeed.

A minimal fix would be moving setIsDirty(false) into the onSuccess callback of the submitBatch mutation so that the dirty flag is cleared only after confirmed successful submission.

---

🚨 DO NOT EDIT BELOW THIS LINE 🚨

Instructions for Requesting Assignment:

To request assignment, please clearly outline your solution and timeline by commenting on the issue using the format below:

Describe your solution clearly:
Provide a detailed explanation of your proposed solution, including your approach, key implementation steps, and relevant examples or references. Mention any dependencies, assumptions, or risks you foresee that might affect your timeline or implementation.

Expected Timeline:

• End date: [Expected submission date of a completed Pull Request]

Additional Context:
Include any other relevant context, links, screenshots, or resources that support your proposed solution.

🚨 Your assignment may be unassigned if there is no activity or progress within the stated timeline unless communicated clearly and agreed upon.

[RITVIKKAMASETTY]

hi @anusha19murthy
I would like to work on this issue.
Solution:
The fix involves moving setIsDirty(false) from the top of handleSubmit (where it runs before validation and before submitBatch resolves) into the onSuccess callback of the submitBatch mutation. This ensures the navigation guard (useNavigationPrompt) remains active until the form is confirmed submitted successfully. If client-side validation fails or the server returns an error, isDirty stays true and the user will receive the unsaved changes warning on navigation.
No other files need to be changed. The fix is a single-line relocation within QuestionnaireForm.tsx.
Expected Timeline
End date: February 22, 2026

[KshitijShukla30]

Hi @anusha19murthy
I'd like to work on this issue.
Proposed Solution
The root cause seems to be that the dirty state is being cleared too early in the submission flow — before we know whether validation or the server request actually succeeded. The navigation guard (useNavigationPrompt) relies on this flag, so clearing it prematurely means users can navigate away without any warning after a failed submit.
The fix would be to defer clearing the dirty flag until we have confirmation that submission was successful, which aligns with how the draft save flows already handle it in the codebase.
Expected Timeline
End date: February 22, 2026