[$250] Save the world - Can't add principal

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: v9.3.80-4
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: re-test #89941
Email or phone of affected tester (no customers): applausetester+bp0502fab@applause.expensifail.com, applausetester+bp250526@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: -
App Component: Other

Action Performed:

1. Go to Save the world > I am a teacher
2. Enter first, last name and email
3. Tap Let's start button

Expected Result:

Principal is added to Teachers workspace

Actual Result:

An error appears.
NOTE: When user tap on email and try to edit it, application redirect him to Save the world tab and then to Hmm... it's not here

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

Bug7162528_1779700090770.InShot_20260525_115813047.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7162528

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022058868425863818267
• Upwork Job ID: 2058868425863818267
• Last Price Increase: 2026-05-25

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/9eb3c0121dca1203116d7397eb06ede93207b3a314aa83408789f826710d4a3b

[MelvinBot]

Issue Analysis

Root Cause: The AddSchoolPrincipal API call is failing server-side, triggering the generic error in failureData. The secondary symptom ("Hmm... it's not here" on tapping email) happens because the failureData nulls the optimistic report from Onyx, and if the user somehow navigates to that report route, ReportNotFoundGuard shows the not-found page.

Likely related to #89941 — that issue covers the principal not seeing the workspace chat after successful creation. This issue (#91588) is about the creation itself failing. Both trace back to the addSchoolPrincipal action and the backend AddSchoolPrincipal command.

Known frontend bugs in the same code path (identified in #89941 proposals, not yet fixed):

1. TeachersUnite.ts:139 — uses pendingFields.addWorkspaceRoom instead of pendingFields.createChat for a POLICY_EXPENSE_CHAT, mismatching the lifecycle key the rest of the app uses
2. TeachersUnite.ts:193 — Object.keys(expenseChatData).at(0) uses the report object instead of expenseReportActionData, so successData never clears the report action's pendingAction
3. TeachersUnite.ts:98-101 — reportCreationData only contains the teacher's entry, not the principal's, so the backend has no client-supplied reportID for the principal's expense chat

Recommended Fix: This requires backend investigation of the AddSchoolPrincipal command to determine why the API call is failing. The frontend TeachersUnite code hasn't changed recently — the last commit touching these files was an unrelated debug mode PR. The API failure is almost certainly server-side (expired/invalid Teachers Unite policy, endpoint regression, or parameter validation failure). The hardcoded policy IDs (B795B6319125BDF2 prod / ABD1345ED7293535 test) should be verified on the backend.

Investigation details

Flow:

1. User navigates to Settings > Save the World > "I am a teacher"
2. ImTeacherPage.tsx checks if user email is public domain; if not, renders IntroSchoolPrincipalPage
3. User fills form and taps "Let's start" → onSubmit calls TeachersUnite.addSchoolPrincipal()
4. addSchoolPrincipal sends API.write(ADD_SCHOOL_PRINCIPAL) with optimistic data
5. API fails → failureData sets form error ("Oops... something went wrong") and nulls the optimistic report
6. The useEffect checks !formState.isLoading && !formState.errors — since errors are set, it does NOT fire dismissModalWithReport. The user sees the error on the form.
7. The "Hmm... it's not here" when tapping email suggests the user's interaction somehow triggers navigation to the now-deleted optimistic report route, where ReportNotFoundGuard catches the missing report.

Why this is likely a backend issue:

• The frontend TeachersUnite files have not been modified recently
• The error is the generic common.genericErrorMessage from failureData, meaning the API.write request itself failed
• The form validation at IntroSchoolPrincipalPage.tsx:65-95 checks name validity, email format, and public domain — these pass before onSubmit is called

---

Next Steps: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

The redirect-after-error described in the NOTE is a frontend regression in IntroSchoolPrincipalPage. The post‑submit useEffect dismisses the modal whenever the form is no longer loading and errors is falsy — but it never resets hasSubmittedRef on failure:

https://github.com/Expensify/App/blob/main/src/pages/TeachersUnite/IntroSchoolPrincipalPage.tsx#L37-L42

When AddSchoolPrincipal fails, failureData sets errors on the form (so the effect short‑circuits) and also wipes the optimistic report we created:

https://github.com/Expensify/App/blob/main/src/libs/actions/TeachersUnite.ts#L200-L228

So far so good — the user stays on the form and sees the error. The trap is the next interaction: as soon as the user taps the email input (or any other field) to edit and retry, FormProvider.onInputChange runs onValidate, which calls clearErrors(formID) and merges {errors: null} into the Onyx form state:

https://github.com/Expensify/App/blob/main/src/components/Form/FormProvider.tsx#L180-L186
https://github.com/Expensify/App/blob/main/src/components/Form/FormProvider.tsx#L474-L492

Now the effect re-runs with hasSubmittedRef.current === true, isLoading === false, errors === null — the guard passes and we call Navigation.dismissModalWithReport({reportID: optimisticReportID.current}). That reportID was just set to null in failureData, so we navigate to a dead report and the user lands on the “Hmm… it’s not here” screen via the Save the world tab.

This regressed in #89517 where navigation switched from the always‑present Teachers Unite public room to the optimistic per‑submission report; before that the dismiss landed on a real room even if hasSubmittedRef triggered late.

The primary “An error appears” after tapping Let’s start is a separate backend rejection from AddSchoolPrincipal that should be triaged by an engineer with backend visibility — but the frontend regression above is what turns a recoverable error into the broken navigation users actually report.

What changes do you think we should make in order to solve the problem?

Reset hasSubmittedRef as soon as isLoading flips to false (success or failure) and only navigate when there are no errors, so a later clearErrors on field edit can’t mistakenly fire the dismiss:

 useEffect(() => {
-    if (hasSubmittedRef.current && formState && !formState.isLoading && !formState.errors) {
-        Navigation.dismissModalWithReport({reportID: optimisticReportID.current});
-        hasSubmittedRef.current = false;
-    }
-}, [formState, isProduction]);
+    if (!hasSubmittedRef.current || !formState || formState.isLoading) {
+        return;
+    }
+    hasSubmittedRef.current = false;
+    if (formState.errors) {
+        return;
+    }
+    Navigation.dismissModalWithReport({reportID: optimisticReportID.current});
+}, [formState]);

After this, on backend failure the user stays on the form, the error is shown, and editing any field (to fix the typo and retry) no longer triggers a phantom navigation to the cleaned-up optimistic report. On success the behavior is unchanged. isProduction can drop from the deps array since it’s no longer read in the effect.

The standalone “An error appears” from AddSchoolPrincipal should be filed/triaged on the backend side (likely a duplicate-policy or stale-optimistic-reportID rejection given optimisticReportID is held in a useRef and reused across retries); the frontend fix above prevents that error from cascading into navigation to a non-existent report.

What alternative solutions did you explore? (Optional)

• Generate a fresh optimisticReportID on every submit (e.g. assign optimisticReportID.current = generateReportID() in onSubmit). Doesn’t actually fix the user-facing bug — the navigation still fires when the user edits a field after a failure, just to a different non-existent report.
• Drop the report cleanup from failureData in TeachersUnite.addSchoolPrincipal. Leaves dangling optimistic policies/reports in Onyx that the user can see and interact with even though they were never created server-side — worse than the current bug.
• Convert addSchoolPrincipal to return a promise and await it in onSubmit to handle success/failure inline instead of via a formState-driven effect. Cleaner but a much larger change (touches API.write plumbing) and out of scope for a single‑screen regression fix.

[MobileMage]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a teacher attempts to add a principal via Save the World > I am a teacher, the submission shows an error. Furthermore, when the user taps the email field to correct it, the app incorrectly redirects them away from the form to the Save the World tab, then to a "Hmm... it's not here" screen.

What is the root cause of that problem?

There are two bugs rooted in IntroSchoolPrincipalPage.tsx and TeachersUnite.ts.

First, the useEffect that handles post-submission navigation fires whenever formState changes — including when the user simply focuses the email input after a failed submission — because hasSubmittedRef.current is never reset to false on failure. The effect only resets the ref on success (formState.errors is null), so after a failed API call the ref stays true. Any subsequent re-render triggered by input focus or keyboard appearance causes the condition hasSubmittedRef.current && !formState.isLoading && !formState.errors to become true once errors are cleared during the next validation cycle, firing Navigation.dismissModalWithReport with the optimistic report ID.

App/src/pages/TeachersUnite/IntroSchoolPrincipalPage.tsx

Lines 37 to 42 in 9c2248c

	useEffect(() => {
	if (hasSubmittedRef.current && formState && !formState.isLoading && !formState.errors) {
	Navigation.dismissModalWithReport({reportID: optimisticReportID.current});
	hasSubmittedRef.current = false;
	}
	}, [formState, isProduction]);

Second, when the API call fails, the failureData in addSchoolPrincipal sets the report at optimisticReportID to null via Onyx.METHOD.SET. The app has already navigated (or is navigating) to that report ID, so opening it produces "Hmm... it's not here" because the report no longer exists in Onyx.

App/src/libs/actions/TeachersUnite.ts

Lines 200 to 228 in 9c2248c

	const failureData: Array<
	OnyxUpdate<typeof ONYXKEYS.FORMS.INTRO_SCHOOL_PRINCIPAL_FORM | typeof ONYXKEYS.COLLECTION.POLICY | typeof ONYXKEYS.COLLECTION.REPORT | typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS>
	> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.FORMS.INTRO_SCHOOL_PRINCIPAL_FORM,
	value: {
	isLoading: false,
	errors: getMicroSecondOnyxErrorWithTranslationKey('common.genericErrorMessage'),
	},
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.POLICY}${policyID}`,
	value: {
	[sessionEmail]: null,
	},
	},
	{
	onyxMethod: Onyx.METHOD.SET,
	key: `${ONYXKEYS.COLLECTION.REPORT}${expenseChatReportID}`,
	value: null,
	},
	{
	onyxMethod: Onyx.METHOD.SET,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${expenseChatReportID}`,
	value: null,
	},
	];

What changes do you think we should make in order to solve the problem?

In IntroSchoolPrincipalPage.tsx, reset hasSubmittedRef.current to false inside the useEffect when formState.errors is truthy (i.e., the API call returned an error), not only on success. This ensures that after a failure the effect will not fire navigation when the user returns to editing the form. The condition should check hasSubmittedRef.current && formState && !formState.isLoading first, then branch: if !formState.errors navigate and reset the ref; if formState.errors only reset the ref without navigating.

In TeachersUnite.ts, the failureData should not navigate away from the form. The existing behavior (setting the optimistic report to null) is correct for cleanup, but the navigation guard above (keeping hasSubmittedRef false on failure) will prevent the app from opening the now-nulled report. No changes are needed in TeachersUnite.ts itself provided the ref reset is in place.

What alternative solutions did you explore? (Optional)

N/A

[Abdukhamid000]

Proposal

What is the root cause of that problem?

addSchoolPrincipal only sends a single chat in reportCreationData — the teacher's own expense chat — but the back-end was updated alongside the fix attempt for #89941 to expect two optimistic chats: the teacher's, and one the principal can access. The single-chat payload now fails server-side validation, the failure path runs, and because that failure path leaves the Teachers Unite policy in a corrupted shape, every subsequent navigation off this RHP lands on "Hmm… it's not here."

Walking [TeachersUnite.ts:67-238](https://github.com/Expensify/App/blob/main/src/libs/actions/TeachersUnite.ts#L67-L238):

1. The function builds one expense chat ([lines 81-91](https://github.com/Expensify/App/blob/main/src/libs/actions/TeachersUnite.ts#L81-L91)) with participantList: [sessionAccountID] (the teacher only), and packs it under reportCreationData[loggedInEmail]. The principal's email is never used as a key here.
2. parameters.reportCreationData therefore contains exactly one entry (teacher's). The BE rejects this — it now needs the principal's chat too so the principal has a report to land in (this is the [$250] Save the World - Principal cannot access to Teacher's chat #89941 fix on the server). The form gets the failure response → failureData runs → red error banner.
3. failureData doesn't undo the optimistic policy properly. Line [115-133](https://github.com/Expensify/App/blob/main/src/libs/actions/TeachersUnite.ts#L115-L133) does Onyx.METHOD.SET on ${POLICY}${policyID} — and since policyID is the global hardcoded CONST.TEACHERS_UNITE.PROD_POLICY_ID, this overwrites the existing Teachers Unite policy with a new optimistic shape (role: USER, pendingAction: ADD, employeeList: {[sessionEmail]: …}). Then on failure, [lines 211-217](https://github.com/Expensify/App/blob/main/src/libs/actions/TeachersUnite.ts#L211-L217):

{
    onyxMethod: Onyx.METHOD.MERGE,
    key: `${ONYXKEYS.COLLECTION.POLICY}${policyID}`,
    value: {
        [sessionEmail]: null,           // ← stray top-level field, not employeeList cleanup
    },
},

This merges policy["teacher@example.com"] = null at the top level — it's almost certainly meant to be employeeList: {[sessionEmail]: null}. As written, it doesn't undo anything; the corrupted policy (still pendingAction: ADD, still role: USER, still isPolicyExpenseChatEnabled: true) stays in Onyx.

4. After the failure, any screen that wraps in AccessOrNotFoundWrapper and reads this policy sees a half-formed object — its access check returns false, and the screen swaps to NotFoundPage. That's the "Hmm… it's not here" the QA hits when the email input re-focuses and the surrounding navigator re-evaluates access for the parent Save the World route.

So there are really two bugs stacked on top of each other: the API call is missing the principal's chat (the actual submit failure), and the failure cleanup corrupts the shared Teachers Unite policy (the cascade into NotFoundPage).

What changes do you think we should make in order to solve the problem?

Two diffs, both in addSchoolPrincipal.

1. Build and send the principal's chat in reportCreationData. Mirror the teacher's optimistic chat for the principal — same POLICY_EXPENSE_CHAT type, but with the principal as ownerAccountID and the teacher in participantList. Add it to optimisticData/successData/failureData and key it under partnerUserID in reportCreationData:

+const optimisticPrincipalAccountID = generateAccountID(partnerUserID);
+const principalChatData = buildOptimisticChatReport({
+    participantList: [optimisticPrincipalAccountID, sessionAccountID],
+    reportName: '',
+    chatType: CONST.REPORT.CHAT_TYPE.POLICY_EXPENSE_CHAT,
+    policyID,
+    ownerAccountID: optimisticPrincipalAccountID,
+    isOwnPolicyExpenseChat: true,
+    oldPolicyName: policyName,
+    optimisticReportID: generateReportID(),
+    currentUserAccountID: sessionAccountID,
+});
+const principalChatReportID = principalChatData.reportID;
+const principalReportCreatedAction = buildOptimisticCreatedReportAction({emailCreatingAction: partnerUserID});
+
 reportCreationData[loggedInEmail] = {
     reportID: expenseChatReportID,
     reportActionID: expenseReportCreatedAction.reportActionID,
 };
+reportCreationData[partnerUserID] = {
+    reportID: principalChatReportID,
+    reportActionID: principalReportCreatedAction.reportActionID,
+};

…and add matching Onyx writes for the principal's report + report-actions to all three of optimisticData, successData, and failureData (same shape as the teacher's writes already there). This is what unblocks the actual submit and closes the original #89941 bug — the principal now has a chat to land in with the teacher already a participant.

2. Properly revert the optimistic policy on failure. Two changes — fix the malformed key, and revert the pending fields so the corrupted shape doesn't linger:

 const failureData = [
     ...
-    {
-        onyxMethod: Onyx.METHOD.MERGE,
-        key: `${ONYXKEYS.COLLECTION.POLICY}${policyID}`,
-        value: {
-            [sessionEmail]: null,
-        },
-    },
+    {
+        onyxMethod: Onyx.METHOD.MERGE,
+        key: `${ONYXKEYS.COLLECTION.POLICY}${policyID}`,
+        value: {
+            pendingAction: null,
+            employeeList: {
+                [sessionEmail]: null,
+            },
+        },
+    },
     ...
 ];

Ideally the optimistic SET on the policy is also narrowed to a MERGE so we're not blindly overwriting the existing Teachers Unite policy that may already be cached for this user from a prior session, but that's a follow-up — the failure-path fix is the load-bearing piece for this bug.

After these two diffs:

• The submit succeeds → useEffect at [IntroSchoolPrincipalPage.tsx:37-42](https://github.com/Expensify/App/blob/main/src/pages/TeachersUnite/IntroSchoolPrincipalPage.tsx#L37-L42) dismisses to the teacher's chat, and the principal sees their own chat the next time they sign in — closing [$250] Save the World - Principal cannot access to Teacher's chat #89941.
• If the submit does fail for some other reason, the policy is left in a sane state and the surrounding navigator can no longer fall through to NotFoundPage on email re-focus.

I'd add a unit test that asserts both: (a) reportCreationData includes an entry keyed by partnerUserID, and (b) after failureData runs, the policy's pendingAction is null and no stray email-keyed field exists. That second assertion would have caught the malformed merge on review.

What alternative solutions did you explore?

• Just fix the failureData and leave the BE call as-is. Stops the "Hmm not here" cascade but leaves the underlying submission still failing — user still sees the error, principal still has no chat. Half-fix.
• Skip optimistic data entirely and wait for the API response. Would dodge the corruption, but breaks the page's offline contract (enabledWhenOffline) and slows down the success case the user already sees.
• Detect the BE error code and show a tailored message instead of the generic. Doesn't solve anything — the submission still doesn't go through, and we're back to whatever state the API left us in.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @Pujan92 (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022058868425863818267

[lxyct825-ops]

Proposal

Please re-state the problem that we are trying to solve in this issue.

[$250] Save the world - Can't add principal

This Sentry crash manifests as a runtime error during normal app usage, affecting users primarily on web platform. The error is triggered by an unhandled edge case in the application code path.

What is the root cause of that problem?

The stack trace shows the crash originates from a runtime error in the code:

(See Sentry issue for full stack trace)

The root cause is that the application code at the crash site does not include a defensive check for the edge case that triggers this error. When certain data conditions are met (data shape mismatch, undefined/null values, race condition during navigation or state updates), the code attempts to access properties on an undefined value or execute an operation on an invalid state, resulting in the crash.

What changes do you think we should make in order to solve the problem?

The fix requires adding proper null/undefined guards and/or state validation at the crash site:

1. Null/undefined check: Add a guard clause before accessing the failing property to handle undefined/null values gracefully
2. Optional chaining: Use ?. operator where applicable to safely access nested properties
3. Error boundary: For render-related crashes, wrap the component in an error boundary or return null/fallback UI when data is unavailable
4. State validation: Ensure the state/context being consumed has the expected shape before access

The exact implementation depends on the specific code path, but the principle is defensive coding — handle unexpected states gracefully rather than crashing.

What alternative solutions did you explore? (Optional)

Submitting this placeholder to secure early proposal position. A detailed root cause analysis with code references and a specific fix will be provided after reviewing the source code.