[$250] Public room - Public room not display in LHN after anon user login from a thread of public room

[lanitochka17]

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.73-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-28527/folder/13176964/41237765/1410973210
Email or phone of affected tester (no customers): lekima20+69605@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Win 11/Chrome
App Component: Other

Action Performed:

1. Navigate to this link - https://staging.new.expensify.com/r/1540486774487195 as anon user
2. Click on any thread on the public room
3. Click on Sign in button at bottom-right corner
4. Log in with a new account and complete onboarding flow
5. Click on Inbox tab

Expected Result:

Public room should display in LHN

Actual Result:

Public room isn't displayed in LHN

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7152910_1778677039498.Recording__2070.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022054600157022292037
• Upwork Job ID: 2054600157022292037
• Last Price Increase: 2026-05-20

Issue Owner

Current Issue Owner: @blimpich

[MelvinBot]

Proposal

What is the root cause of that problem?

When an anonymous user signs in from a public room thread, the SignInModal calls openApp(shouldKeepPublicRooms=true), which preserves the public room report in Onyx via a merge in App.ts:380-393. However, the preserved report still contains the anonymous user's accountID in its participants field — the newly authenticated user is not a participant.

When getReportNotificationPreference looks up the authenticated user's accountID in report.participants, it doesn't find it and defaults to HIDDEN. The LHN then filters it out via isHiddenForCurrentUser.

There is no mechanism to auto-join the parent public room after the anonymous-to-authenticated transition. The SignInModal navigates to ROUTES.HOME after sign-in, the OnboardingGuard redirects new users to onboarding, and the user never returns to the public room context.

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

In SignInModal, before navigating to ROUTES.HOME, we should find any public room reports preserved in Onyx (via the same isPublicRoom check used by shouldKeepPublicRooms) where the current authenticated user is NOT in the participants, and call joinRoom for each of them. This ensures the server adds the authenticated user as a participant with a visible notificationPreference, so the public room appears in the LHN after sign-in completes.

The join should happen after openApp finishes (i.e., when IS_LOADING_APP becomes false) but before navigation to HOME, so the room is already joined by the time the LHN renders.

What alternative solutions did you explore? (Optional)

1. Modify shouldKeepPublicRooms to also update the participants field — This would be a client-only optimistic fix and wouldn't actually register the user as a participant on the server. The report would still be missing from the server's response on subsequent OpenApp calls.

2. Navigate back to the public room after onboarding instead of HOME — This only addresses the navigation aspect but doesn't fix the HIDDEN notification preference, so the room still wouldn't appear in the LHN sidebar.

3. Re-fetch the parent public room report via OpenReport after sign-in — This would load fresh data but still wouldn't join the user to the room, so the notification preference issue would persist.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-13 16:49:46 UTC.

Replaces my earlier proposal. The earlier body correctly followed the anonymous sign-in/OpenApp path, but the proposed parent OpenReport refresh was incomplete: the room stays hidden until the signed-in account gets a visible notification preference through the existing join path.

Proposal

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

After an anonymous user opens a public room, enters one of its threads, signs in as a new user, completes onboarding, and goes to Inbox, the parent public room is missing from the LHN.

What is the root cause of that problem?

In this repro the user opens the parent public room first, then enters a thread from that room. So the parent room is already in Onyx before sign-in. SignInModal then switches the anonymous session into a signed-in session and calls openApp(true):

App/src/pages/signin/SignInModal.tsx

Lines 39 to 48 in c5403b4

	useEffect(() => {
	const isAnonymousUser = session?.authTokenType === CONST.AUTH_TOKEN_TYPES.ANONYMOUS;
	if (!isAnonymousUser) {
	hasSignedInRef.current = true;
	// To prevent deadlock when OpenReport and OpenApp overlap, wait for the queue to be idle before calling openApp.
	// This ensures that any communication gaps between the client and server during OpenReport processing do not cause the queue to pause,
	// which would prevent us from processing or clearing the queue.
	waitForIdle().then(() => openApp(true));
	}

OpenApp preserves public rooms that are already in allReports, but it preserves the anonymous copy of the report:

App/src/libs/actions/App.ts

Lines 380 to 390 in c5403b4

	if (shouldKeepPublicRooms) {
	const publicReports = Object.values(allReports ?? {}).filter((report) => isPublicRoom(report) && isValidReport(report));
	if (publicReports) {
	for (const report of publicReports) {
	result.successData?.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${report?.reportID}`,
	value: {
	...report,
	},
	});

That preserved report does not have a visible participants[currentUserAccountID].notificationPreference for the newly signed-in account. getReportNotificationPreference() therefore falls back to HIDDEN:

App/src/libs/ReportUtils.ts

Lines 1878 to 1886 in c5403b4

	/**
	* Get the notification preference given a report. This should ALWAYS default to 'hidden'. Do not change this!
	*/
	function getReportNotificationPreference(report: OnyxEntry<Report>): ValueOf<typeof CONST.REPORT.NOTIFICATION_PREFERENCE> {
	const participant = deprecatedCurrentUserAccountID ? report?.participants?.[deprecatedCurrentUserAccountID] : undefined;
	// Empty notification preference should return `hidden`
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
	return participant?.notificationPreference || CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN;

and once SignInModal dismisses and navigates Home, the public room is no longer the focused report:

App/src/pages/signin/SignInModal.tsx

Lines 55 to 62 in c5403b4

	useEffect(() => {
	if (!hasSignedInRef.current || isLoadingApp !== false) {
	return;
	}
	Navigation.dismissModal();
	Navigation.navigate(ROUTES.HOME);
	}, [isLoadingApp]);

so SidebarUtils.shouldDisplayReportInLHN() drops it as hidden:

App/src/libs/SidebarUtils.ts

Lines 318 to 332 in c5403b4

	// Check if report should override hidden status
	const requiresAttention = reportAttributes?.[report?.reportID]?.requiresAttention;
	const isSystemChat = isSystemChatUtil(report);
	const shouldOverrideHidden =
	!!draftComment ||
	hasErrorsOtherThanFailedReceipt ||
	isFocused ||
	isSystemChat ||
	!!report.isPinned ||
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
	requiresAttention ||
	(report.isOwnPolicyExpenseChat && !isReportArchived);
	if (isHidden && !shouldOverrideHidden) {
	return {shouldDisplay: false};

The missing step is not another OpenReport read. The existing client path that turns a hidden public room into a joined/visible room is joinRoom(), which calls updateNotificationPreference() and writes participants[currentUserAccountID].notificationPreference optimistically before sending UPDATE_REPORT_NOTIFICATION_PREFERENCE:

App/src/libs/actions/Report/index.ts

Lines 3320 to 3376 in c5403b4

	function updateNotificationPreference(
	reportID: string,
	previousValue: NotificationPreference | undefined,
	newValue: NotificationPreference,
	currentUserAccountID: number,
	parentReportID?: string,
	parentReportActionID?: string,
	) {
	// No change needed
	if (previousValue === newValue) {
	return;
	}
	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT | typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value: {
	participants: {
	[currentUserAccountID]: {
	notificationPreference: newValue,
	},
	},
	},
	},
	];
	const failureData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT | typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value: {
	participants: {
	[currentUserAccountID]: {
	notificationPreference: previousValue,
	},
	},
	},
	},
	];
	if (parentReportID && parentReportActionID) {
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${parentReportID}`,
	value: {[parentReportActionID]: {childReportNotificationPreference: newValue}},
	});
	failureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${parentReportID}`,
	value: {[parentReportActionID]: {childReportNotificationPreference: previousValue}},
	});
	}
	const parameters: UpdateReportNotificationPreferenceParams = {reportID, notificationPreference: newValue};
	API.write(WRITE_COMMANDS.UPDATE_REPORT_NOTIFICATION_PREFERENCE, parameters, {optimisticData, failureData});

App/src/libs/actions/Report/index.ts

Lines 4772 to 4783 in c5403b4

	function joinRoom(report: OnyxEntry<Report>, currentUserAccountID: number) {
	if (!report) {
	return;
	}
	updateNotificationPreference(
	report.reportID,
	getReportNotificationPreference(report),
	getDefaultNotificationPreferenceForReport(report),
	currentUserAccountID,
	report.parentReportID,
	report.parentReportActionID,
	);

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

In SignInModal, remember the report the user was viewing when the anonymous session becomes signed in, then join that public room before navigating Home after OpenApp finishes.

Concretely:

1. Add a ref such as signInOriginReportIDRef and set it to Navigation.getTopmostReportId() in the first sign-in effect before calling openApp(true).
2. Subscribe to ONYXKEYS.COLLECTION.REPORT in SignInModal.
3. In the isLoadingApp === false effect, derive the report to join from that origin report ID: if the origin report is a chat thread, use its parentReportID; otherwise use the origin report itself.
4. If that derived report is a valid public room and it is still hidden for the newly signed-in account, call joinRoom(publicRoomReport, session.accountID) before Navigation.dismissModal() and Navigation.navigate(ROUTES.HOME).

Scope boundaries:

• Files touched: src/pages/signin/SignInModal.tsx - imports for joinRoom and report helpers, a sign-in-origin ref near the current refs, the current sign-in effect at lines 39-48, and the post-OpenApp navigation effect at lines 55-62.
• Platforms: all platforms through the shared sign-in modal; the reported Windows/Chrome path is covered.
• Code paths explicitly not touched: ReportFetchHandler, openReportFromDeepLink, openApp public-room preservation, onboarding guards, generic LHN filtering, non-public reports, and unrelated public rooms that were not the sign-in origin.
• API contracts or backend behavior changes: no; this reuses the existing joinRoom -> UPDATE_REPORT_NOTIFICATION_PREFERENCE path.

What alternative solutions did you explore? (Optional)

My earlier ReportFetchHandler/parent OpenReport refresh is not enough because it only re-reads report data. It does not write the signed-in account's visible notification preference, so the LHN can still treat the room as hidden after Home navigation.

MobileMage and aswin-s point at openReportFromDeepLink not fetching the parent room. That would matter for a direct thread deep link, but the reported flow and video open the parent public room first, so the parent report is already present before sign-in.

MelvinBot and trasnake87 use the right join mechanism, but they join every preserved public room. I would scope the auto-join to the report the user signed in from, or that report's parent when the origin is a thread, so an unrelated public room visited earlier in the anonymous session is not silently joined.

After Fix
after_fix1778759439434138.mp4

[melvin-bot]

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

[melvin-bot]

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

[MobileMage]

Proposal

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

When an anonymous user navigates directly to a thread inside a public room and then signs in with a new account, the parent public room does not appear in the LHN after onboarding completes, even though the thread itself was the entry point to the app.

What is the root cause of that problem?

When an anonymous user opens a deep link pointing to a thread (e.g. /r/<threadReportID>), openReportFromDeepLink in Link.ts calls openReport with only the thread's reportID. The server's OpenReport response populates Onyx with data for the thread but does not necessarily populate a standalone report entry for the parent public room under ONYXKEYS.COLLECTION.REPORT<parentReportID>.

When the user subsequently signs in via the sign-in button, SignInModal calls openApp(true) (with shouldKeepPublicRooms = true). The getOnyxDataForOpenOrReconnect function in App.ts scans the current allReports Onyx collection to find any public rooms and adds them to successData so they survive the OpenApp report-list reset. Because the parent public room was never written to allReports as its own entry (only the thread was opened), the scan at line 381 of App.ts finds nothing to preserve. After OpenApp completes, the new user's server-side report list does not include the public room (they have not explicitly joined it), so the parent public room is absent from the LHN entirely.

App/src/libs/actions/App.ts

Lines 380 to 393 in c5403b4

	if (shouldKeepPublicRooms) {
	const publicReports = Object.values(allReports ?? {}).filter((report) => isPublicRoom(report) && isValidReport(report));
	if (publicReports) {
	for (const report of publicReports) {
	result.successData?.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${report?.reportID}`,
	value: {
	...report,
	},
	});
	}
	}
	}

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

In openReportFromDeepLink in src/libs/actions/Link.ts, after calling openReport for the deep-linked report, the code should check whether that report is a thread (i.e. it has a parentReportID) and, if so, also call openReport for the parentReportID. At the time openReportFromDeepLink executes, the thread report may already be in the reports collection passed as a parameter; if so, the parentReportID can be read directly. If the thread is not yet in the collection (it is being fetched for the first time), the code should subscribe to the Onyx key for the thread report and, once it arrives with a parentReportID, call openReport on that parent. This ensures the parent public room is written into allReports before openApp(true) fires in SignInModal, so the shouldKeepPublicRooms preservation logic at line 381 of App.ts can find it and add it to successData.

Concretely, after the openReport({reportID, ...}) call at line 245 of Link.ts, add logic that reads reports?.[ONYXKEYS.COLLECTION.REPORT + reportID]?.parentReportID and, if present (meaning the report is a thread with a known parent), calls openReport({reportID: parentReportID, isFromDeepLink: false, ...}). If the parent is not yet available, use Onyx.connectWithoutView on the thread report key and trigger the parent openReport call as soon as the thread data arrives with a parentReportID, disconnecting immediately after. This mirrors the existing pattern used elsewhere in Link.ts (lines 351–360) to wait for report data before acting.

App/src/libs/actions/Link.ts

Lines 225 to 255 in c5403b4

	function openReportFromDeepLink(
	url: string,
	reports: OnyxCollection<Report>,
	isAuthenticated: boolean,
	conciergeReportID: string | undefined,
	introSelected: OnyxEntry<IntroSelected>,
	isSelfTourViewed: boolean | undefined,
	betas: OnyxEntry<Beta[]>,
	) {
	const reportID = getReportIDFromLink(url);
	if (reportID && !isAuthenticated) {
	// Start span for public room API call
	startSpan(CONST.TELEMETRY.SPAN_BOOTSPLASH.PUBLIC_ROOM_API, {
	name: CONST.TELEMETRY.SPAN_BOOTSPLASH.PUBLIC_ROOM_API,
	op: CONST.TELEMETRY.SPAN_BOOTSPLASH.PUBLIC_ROOM_API,
	parentSpan: getSpan(CONST.TELEMETRY.SPAN_BOOTSPLASH.PUBLIC_ROOM_CHECK),
	});
	// Call the OpenReport command to check in the server if it's a public room. If so, we'll open it as an anonymous user
	openReport({reportID, introSelected, parentReportActionID: '0', isFromDeepLink: true, betas});
	// Show the sign-in page if the app is offline
	if (getIsOffline()) {
	endSpan(CONST.TELEMETRY.SPAN_BOOTSPLASH.PUBLIC_ROOM_API);
	doneCheckingPublicRoom();
	}
	} else {
	// If we're not opening a public room (no reportID) or the user is authenticated, we unblock the UI (hide splash screen)
	doneCheckingPublicRoom();
	}

What alternative solutions did you explore? (Optional)

An alternative would be to extend the shouldKeepPublicRooms logic in getOnyxDataForOpenOrReconnect to also walk the parentReportID chain of any reports currently in allReports and preserve those ancestor reports if they are public rooms. This would catch the case without modifying the deep-link flow, but it adds complexity to a function that runs on every OpenApp and ReconnectApp call, whereas fixing the deep-link entry point is more targeted and correct by design. Another option would be to have the server return the parent report as part of the OpenReport response for threads — but that is a backend change outside the scope of this issue.

[aswin-s]

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

When an anonymous user opens a deep link to a thread inside a public room (e.g., /r/<threadID>), signs in as a new user, and completes onboarding, the public room does not appear in the LHN. The user expects the public room to be visible alongside other accessible rooms after sign-in, but instead only their joined rooms are shown because the parent public room was never written to Onyx during the anonymous deep-link flow.

What is the root cause of that problem?

In src/libs/actions/Link.ts:244–246, when openReportFromDeepLink is called with a thread reportID, it only calls openReport for that thread. The server returns thread data, but the parent public room is never fetched or stored in allReports as a standalone entry. Later, when SignInModal calls openApp(true) (src/pages/signin/SignInModal.tsx:48), getOnyxDataForOpenOrReconnect in App.ts:380 filters allReports for public rooms:

const publicReports = Object.values(allReports ?? {}).filter((report) => isPublicRoom(report) && isValidReport(report));

Since the thread is not itself a public room and the parent public room is absent from Onyx, this filter matches nothing. After openApp resets the report collection, the newly signed-in user's server-supplied report list also lacks the public room (the user has not joined it), so it never appears in the LHN.

App/src/libs/actions/Link.ts

Lines 244 to 246 in c5403b4

	// Call the OpenReport command to check in the server if it's a public room. If so, we'll open it as an anonymous user
	openReport({reportID, introSelected, parentReportActionID: '0', isFromDeepLink: true, betas});

App/src/pages/signin/SignInModal.tsx

Line 48 in c5403b4

}

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

1. File: src/libs/actions/Link.ts
   Function: openReportFromDeepLink
   Description: After the initial openReport({reportID, ...}) call for the thread, fetch the parent public room using the following logic:

   • Subscribe to the thread's Onyx key (ONYXKEYS.COLLECTION.REPORT + reportID) using Onyx.connect. Store the connection ID so it can be disconnected after use, preventing memory leaks and infinite loops.
   • In the callback, check that report?.parentReportID is a non-empty string before proceeding. If parentReportID is absent or falsy, disconnect and return early — this guards against threads that have no parent or whose parent field has not yet been hydrated.
   • Once a valid parentReportID is confirmed, disconnect the Onyx listener immediately (call Onyx.disconnect(connectionID)) before firing any further action, ensuring the listener fires at most once and cannot loop.
   • Call openReport({reportID: report.parentReportID, isFromDeepLink: true, ...}) to fetch and cache the parent public room. This ensures the parent public room is written to allReports before SignInModal triggers openApp(true), allowing getOnyxDataForOpenOrReconnect to find and preserve it.

   Sketch of the addition (immediately after the existing openReport call for the thread):

   let parentConnectionID: number | undefined;
   parentConnectionID = Onyx.connect({
       key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
       callback: (report) => {
           if (parentConnectionID !== undefined) {
               Onyx.disconnect(parentConnectionID);
               parentConnectionID = undefined;
           }
           const parentReportID = report?.parentReportID;
           if (!parentReportID) {
               return;
           }
           Report.openReport({reportID: parentReportID, isFromDeepLink: true});
       },
   });

   This pattern is safe across both web and mobile: Onyx.connect is the same cross-platform primitive used throughout the codebase for one-time data reads, and disconnecting in the callback before dispatching the side-effect is the standard idiom for avoiding re-entrancy. There is no platform-specific Onyx behavior in this path that requires separate handling.

What alternative solutions did you explore? (Optional)

N/A

[aswin-s]

Updated the proposal above to tighten 4 edge cases (additional guards and broader coverage).

[trasnake87]

Proposal

When an anonymous viewer of a public room signs in (or signs up) from within a thread of that room, the public room remains in Onyx but never appears in the LHN of the newly authenticated session.

Root cause

Two pieces of logic combine to produce the bug.

1 - Public room is preserved in Onyx, but the new account is not a participant

SignInModal triggers openApp(true) once the session transitions out of ANONYMOUS, so the public room is intentionally re-merged into Onyx as part of OpenApp's successData — src/pages/signin/SignInModal.tsx:39-49:

// src/pages/signin/SignInModal.tsx:39-49
useEffect(() => {
    const isAnonymousUser = session?.authTokenType === CONST.AUTH_TOKEN_TYPES.ANONYMOUS;
    if (!isAnonymousUser) {
        hasSignedInRef.current = true;
        // To prevent deadlock when OpenReport and OpenApp overlap, wait for the queue to be idle before calling openApp.
        waitForIdle().then(() => openApp(true));
    }
}, [session?.authTokenType]);

The merge happens in src/libs/actions/App.ts:377-390:

// src/libs/actions/App.ts:377-390
if (shouldKeepPublicRooms) {
    const publicReports = Object.values(allReports ?? {}).filter((report) => isPublicRoom(report) && isValidReport(report));
    if (publicReports) {
        for (const report of publicReports) {
            result.successData?.push({
                onyxMethod: Onyx.METHOD.MERGE,
                key: `${ONYXKEYS.COLLECTION.REPORT}${report?.reportID}`,
                value: {
                    ...report,
                },
            });
        }
    }
}

The report object that is re-merged is the one that was fetched while the viewer was anonymous: its participants map does not contain the freshly created account's accountID. OpenApp's normal response only carries reports the new account is actually a member of, and a public room visited as an anonymous user is not one of them — so nothing in the response writes a participant entry for the new account either.

2 - Missing participant entry collapses notificationPreference to HIDDEN, which LHN filters out

getReportNotificationPreference reads the preference off the current user's slot in report.participants — src/libs/ReportUtils.ts:1888-1897:

// src/libs/ReportUtils.ts:1888-1897
function getReportNotificationPreference(report: OnyxEntry<Report>): ValueOf<typeof CONST.REPORT.NOTIFICATION_PREFERENCE> {
    const participant = deprecatedCurrentUserAccountID ? report?.participants?.[deprecatedCurrentUserAccountID] : undefined;

    // Empty notification preference should return `hidden`
    // eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
    return participant?.notificationPreference || CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN;
}

With no entry for the new accountID, this returns HIDDEN. isHiddenForCurrentUser (src/libs/ReportUtils.ts:2223-2234) then returns true, and SidebarUtils.getOptionData drops the report at src/libs/SidebarUtils.ts:303 / :331-333 because none of the shouldOverrideHidden conditions (draftComment, focused, pinned, system chat, requiresAttention, errors, own policy expense chat) apply to a public room the user has just been signed-in to:

// src/libs/SidebarUtils.ts:303, 331-333
const isHidden = isHiddenForCurrentUser(report);
...
if (isHidden && !shouldOverrideHidden) {
    return {shouldDisplay: false};
}

Net effect: the room sits in Onyx with no participants[newAccountID], the LHN treats it as hidden, and the user only sees an empty Inbox after onboarding even though they explicitly chose to sign in from inside that room.

Proposed fix

After openApp finishes (i.e., once IS_LOADING_APP flips back to false), iterate over the public rooms that shouldKeepPublicRooms just preserved and call joinRoom for any where the newly authenticated accountID is not already a participant. joinRoom already wraps updateNotificationPreference, which short-circuits when previousValue === newValue (src/libs/actions/Report/index.ts:3078-3081), so it is a no-op for rooms the user is already a member of.

Update src/pages/signin/SignInModal.tsx so the second useEffect joins any preserved public rooms before dismissing the modal:

// src/pages/signin/SignInModal.tsx
import React, {useEffect, useMemo, useRef} from 'react';
import HeaderWithBackButton from '@components/HeaderWithBackButton';
import {useSession} from '@components/OnyxListItemProvider';
import ScreenWrapper from '@components/ScreenWrapper';
import useAndroidBackButtonHandler from '@hooks/useAndroidBackButtonHandler';
import useOnyx from '@hooks/useOnyx';
import useStyleUtils from '@hooks/useStyleUtils';
import useTheme from '@hooks/useTheme';
import {openApp} from '@libs/actions/App';
import {isMobileSafari} from '@libs/Browser';
import Navigation from '@libs/Navigation/Navigation';
import {waitForIdle} from '@libs/Network/SequentialQueue';
import {isPublicRoom, isValidReport} from '@libs/ReportUtils';
import {joinRoom} from '@userActions/Report';
import CONST from '@src/CONST';
import ONYXKEYS from '@src/ONYXKEYS';
import ROUTES from '@src/ROUTES';
import SCREENS from '@src/SCREENS';
import SignInPageWrapped, {SignInPage} from './SignInPage';
import type {SignInPageRef} from './SignInPage';

// ...

const [isLoadingApp] = useOnyx(ONYXKEYS.IS_LOADING_APP);
const [allReports] = useOnyx(ONYXKEYS.COLLECTION.REPORT, {canBeMissing: true});

// ...

useEffect(() => {
    if (!hasSignedInRef.current || isLoadingApp !== false) {
        return;
    }

    const currentUserAccountID = session?.accountID;
    if (currentUserAccountID) {
        Object.values(allReports ?? {}).forEach((report) => {
            if (!isPublicRoom(report) || !isValidReport(report)) {
                return;
            }
            if (report?.participants?.[currentUserAccountID]) {
                return;
            }
            joinRoom(report, currentUserAccountID);
        });
    }

    Navigation.dismissModal();
    Navigation.navigate(ROUTES.HOME);
}, [isLoadingApp, allReports, session?.accountID]);

The participant guard (report?.participants?.[currentUserAccountID]) keeps the call to joinRoom cheap and avoids redundant UpdateReportNotificationPreference writes for users who happened to revisit the same room from a non-anonymous session. joinRoom itself resolves the correct preference for the room type via getDefaultNotificationPreferenceForReport (DAILY for public rooms, ALWAYS for public-announce — src/libs/ReportUtils.ts:1869-1886), so both VISIBILITY.PUBLIC and VISIBILITY.PUBLIC_ANNOUNCE are handled correctly. The optimistic data in updateNotificationPreference (src/libs/actions/Report/index.ts:3083-3095) immediately writes participants[currentUserAccountID].notificationPreference = DAILY, which un-hides the room in the LHN on the very next render — i.e., before the user even taps the Inbox tab.

Why this approach

Doing the join on the client mirrors what already happens elsewhere in the app when a logged-in user enters a public room and presses the "Join" promoted action (src/components/PromotedActionsBar.tsx:65-73 and src/pages/inbox/HeaderView.tsx:198) — we reuse the same joinRoom → updateNotificationPreference → UPDATE_REPORT_NOTIFICATION_PREFERENCE path that the server already understands, so the user becomes a real participant on the backend rather than only locally. Two alternatives were considered and rejected: (a) injecting a participant entry directly into the successData of openApp in App.ts:377-390 would un-hide the room only locally and would be wiped by the next ReconnectApp because the backend wouldn't know the user joined; (b) auto-navigating back to the originating public room URL instead of ROUTES.HOME would conflict with OnboardingGuard's redirect for new accounts and would not handle the case where the anonymous session had visited multiple public rooms. Gating the call on isLoadingApp === false ensures the shouldKeepPublicRooms merge in OpenApp's successData has already run, so we are joining the same set of rooms that were preserved rather than racing against the queue.