[$250] Onboarding - Hmm it's not here page displayed when tap on report header for any task

[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: 9.3.75-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/folder/13176924/test-cases/41237572
Email or phone of affected tester (no customers): useronboarding@onboarding051526.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: iOS
App Component: Other

Action Performed:

1. Create a new account on NewDot with the following format - useronboarding@onboarding051526.com
2. Select "Manage my team's expenses"
3. Select the option of "11-50 employees" and click continue > SAP > finish Onboarding
4. Navigate to #admins room > Click on any task
5. Click on the report header

Expected Result:

Details page should be open and there is no Room description field.

Actual Result:

Hmm it's not here page displayed when tap on report header for any task

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7155637_1778899266386.ScreenRecording_05-15-2026_21-30-59_1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022055766445038884482
• Upwork Job ID: 2055766445038884482
• Last Price Increase: 2026-06-13

[MelvinBot]

Proposal

What is the root cause of that problem?

There is an asymmetry between how ReportScreen and ReportDetailsPage guard against "not found" reports.

• ReportScreen uses ReportNotFoundGuard, which only checks whether the report exists in Onyx (!!reportID). It does not check errorFields.notFound.

• ReportDetailsPage uses withReportOrNotFound, which additionally calls canAccessReport — and that returns false when report.errorFields.notFound is set.

During onboarding, task reports are created optimistically with NOTIFICATION_PREFERENCE.HIDDEN. When ReportFetchHandler calls openReport for this task, the server can set errorFields.notFound on the report (e.g., because the CompleteGuidedSetup API hasn't finished creating it server-side, or because the HIDDEN notification preference affects server-side access checks).

The result:

1. The task report remains in Onyx (optimistic data with a valid reportID), so ReportScreen renders it normally.
2. The user clicks the header → navigateToDetailsPage navigates to r/{reportID}/details.
3. withReportOrNotFound on ReportDetailsPage checks canAccessReport → returns false due to errorFields.notFound → shows "Hmm... it's not here".

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

Align withReportOrNotFound's guard logic with ReportNotFoundGuard so they handle errorFields.notFound consistently. Specifically, in withReportOrNotFound.tsx: if the report exists in Onyx and the user was already able to view it in ReportScreen, the details page should not block access based on errorFields.notFound alone.

One approach: skip the canAccessReport check in withReportOrNotFound when the report is loaded and is a task report (since ReportNotFoundGuard already allowed viewing it). Alternatively, ensure the openReport response for onboarding task reports does not set errorFields.notFound.

What alternative solutions did you explore? (Optional)

• Server-side fix to prevent notFound from being set on onboarding task reports — this would be ideal but requires backend changes.
• Clearing errorFields.notFound after CompleteGuidedSetup succeeds — partial fix, wouldn't cover the race condition where openReport runs before the setup completes.

Investigation details

Navigation flow:

• HeaderView.tsx:314 → calls navigateToDetailsPage(report) with the task's own reportID
• ReportUtils.ts:6119-6121 → navigates to r/{reportID}/details
• withReportOrNotFound.tsx:103 → shouldShowNotFoundPage = !isReportLoaded || !canAccessReport(report, betas, isReportArchived)
• ReportUtils.ts:9050 → canAccessReport returns false when report.errorFields.notFound is set

Onboarding task creation:

• Tasks are created optimistically at ReportUtils.ts:11831-11838 with NOTIFICATION_PREFERENCE.HIDDEN
• On CompleteGuidedSetup failure, task reports are set to null in Onyx

Key asymmetry:

• ReportNotFoundGuard (line 51-53): reportExists = !!reportID — no errorFields.notFound check
• withReportOrNotFound (line 103): checks canAccessReport which rejects reports with errorFields.notFound

Possibly related: #89724 — same "Hmm... it's not here" symptom when clicking "View Details" on reports.

Confidence: Medium — the errorFields.notFound mechanism is the most likely cause given the code asymmetry, but production logs would be needed to confirm the server actually sets this flag on onboarding task reports.

---

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-16 21:53:30 UTC.

Replaces my earlier proposal. The prior body correctly identified that admins-room task reports inherit chatType: policyAdmins, but it missed the details-page access guard that actually renders the missing page. This version splits the fix into the access guard and the room-helper classification pieces.

Proposal

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

For onboarding accounts where guided setup posts tasks in the #admins room, opening any task and tapping the task report header navigates to the generic "Hmm, it's not here" page instead of opening that task's details page.

The details page should open for the task report, and it should render task details rather than room-only UI such as the Room description field.

What is the root cause of that problem?

Two client-side assumptions combine here.

Defect 1 - The details-page guard rejects a loaded task report

The main report screen only treats a report as missing when the report does not exist in Onyx after loading:

App/src/pages/inbox/ReportNotFoundGuard.tsx

Lines 51 to 53 in 45f992d

	const reportExists = !!reportID || isOptimisticDelete || userLeavingStatus;
	const shouldShowNotFoundPage = !deleteTransactionNavigateBackUrl && (isInvalidReportPath || (!isLoading && !reportExists));

But the details page is wrapped by withReportOrNotFound(), which rejects any loaded report when canAccessReport() returns false:

App/src/pages/inbox/report/withReportOrNotFound.tsx

Lines 101 to 103 in 45f992d

	if (shouldRequireReportID || isReportIdInRoute) {
	const shouldShowFullScreenLoadingIndicator = !isReportLoaded && (isLoadingReportData !== false || shouldFetchReport);
	const shouldShowNotFoundPage = !isReportLoaded || !canAccessReport(report, betas, isReportArchived);

canAccessReport() returns false whenever report.errorFields.notFound is present:

App/src/libs/ReportUtils.ts

Lines 9044 to 9051 in 45f992d

	function canAccessReport(report: OnyxEntry<Report>, betas: OnyxEntry<Beta[]>, isReportArchived = false): boolean {
	// We hide default rooms (it's basically just domain rooms now) from people who aren't on the defaultRooms beta.
	if (isDefaultRoom(report) && !canSeeDefaultRoom(report, betas, isReportArchived)) {
	return false;
	}
	if (report?.errorFields?.notFound) {
	return false;

So a task report can be visible in ReportScreen, then the header tap navigates to r/:reportID/details, and the details wrapper renders NotFound for the same loaded report because it applies the stricter errorFields.notFound access check.

Defect 2 - Admins-room task reports are classified as rooms

Admins-room onboarding tasks are task reports, but buildOptimisticTaskReport() copies chatType: policyAdmins from the parent #admins room:

App/src/libs/ReportUtils.ts

Lines 8621 to 8652 in 45f992d

	function buildOptimisticTaskReport(
	ownerAccountID: number,
	parentReportID: string,
	assigneeAccountID = 0,
	title?: string,
	description?: string,
	policyID: string = CONST.POLICY.OWNER_EMAIL_FAKE,
	notificationPreference: NotificationPreference = CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN,
	parentChatType?: ValueOf<typeof CONST.REPORT.CHAT_TYPE>,
	): OptimisticTaskReport {
	const participants: Participants = {
	[ownerAccountID]: {
	notificationPreference,
	},
	};
	if (assigneeAccountID) {
	participants[assigneeAccountID] = {notificationPreference};
	}
	return {
	reportID: generateReportID(),
	created: DateUtils.getDBTime(),
	reportName: getParsedComment(title ?? '', undefined, undefined, [...CONST.TASK_TITLE_DISABLED_RULES]),
	description: getParsedComment(description ?? '', {}),
	ownerAccountID,
	participants,
	managerID: assigneeAccountID,
	type: CONST.REPORT.TYPE.TASK,
	// Only #admins tasks inherit chatType for Concierge routing.
	// Task reports are not expense chats, so we do not inherit policyExpenseChat (or other chat types).
	...(parentChatType === CONST.REPORT.CHAT_TYPE.POLICY_ADMINS && {chatType: CONST.REPORT.CHAT_TYPE.POLICY_ADMINS}),

The room helpers then classify that task as an admin/default/chat room because they only inspect chatType, not type:

App/src/libs/ReportUtils.ts

Lines 1642 to 1664 in 45f992d

	function isAdminRoom(report: OnyxEntry<Report>): boolean {
	return getChatType(report) === CONST.REPORT.CHAT_TYPE.POLICY_ADMINS;
	}
	/**
	* Whether the provided report is an Admin-only posting room
	*/
	function isAdminsOnlyPostingRoom(report: OnyxEntry<Report>): boolean {
	return report?.writeCapability === CONST.REPORT.WRITE_CAPABILITIES.ADMINS;
	}
	/**
	* Whether the provided report is a Announce room
	*/
	function isAnnounceRoom(report: OnyxEntry<Report>): boolean {
	return getChatType(report) === CONST.REPORT.CHAT_TYPE.POLICY_ANNOUNCE;
	}
	/**
	* Whether the provided report is a default room
	*/
	function isDefaultRoom(report: OnyxEntry<Report>): boolean {
	return CONST.DEFAULT_POLICY_ROOM_CHAT_TYPES.some((type) => type === getChatType(report));

App/src/libs/ReportUtils.ts

Lines 1770 to 1771 in 45f992d

	function isChatRoom(report: OnyxEntry<Report>): boolean {
	return isUserCreatedPolicyRoom(report) || isDefaultRoom(report) || isInvoiceRoom(report) || isTripRoom(report);

Once the details page is allowed to render, those false room classifications make ReportDetailsPage show room-oriented UI, including the Room description path, for a task report:

App/src/pages/ReportDetailsPage.tsx

Lines 221 to 222 in 45f992d

	const canEditReportDescription = useMemo(() => canEditReportDescriptionUtil(report, policy), [report, policy]);
	const shouldShowReportDescription = isChatRoom && (canEditReportDescription || report.description !== '') && (isTaskReport ? isTaskModifiable : true);

App/src/pages/ReportDetailsPage.tsx

Line 749 in 45f992d

const shouldDisplayGroupWorkspaceAsPushRow = !isThread && (isGroupChat || isUserCreatedPolicyRoom || isDefaultRoom);

Defect 1 causes the "Hmm, it's not here" page. Defect 2 is why the expected task details page would still be wrong unless task reports are excluded from room helpers.

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

Fix both sides while keeping the backend-compatible chatType: policyAdmins value on admins-room task reports.

1. Make the details access guard consistent for loaded task reports. The narrow fix is to allow a loaded type: task report with parent access to pass the details-page guard even if a stale errorFields.notFound value is present. This can be done either in withReportOrNotFound() before calling canAccessReport(), or by teaching canAccessReport() that task reports with valid parent access should not be rejected solely by errorFields.notFound.
2. Update the room/default-room helpers in src/libs/ReportUtils.ts so task reports return false before helper logic inspects chatType. At minimum this covers isAdminRoom(), isAnnounceRoom(), isDefaultRoom(), isDomainRoom(), and isUserCreatedPolicyRoom(), or equivalently makes isChatRoom() and the direct helpers require an actual chat/room report type.
3. Leave buildOptimisticTaskReport() inheriting chatType: policyAdmins; that preserves the FE/BE alignment from [Due for payment 2026-04-14] Align optimistic task chatType with Auth for admins-room tasks #84258 while making type: task authoritative for details-page routing and UI.
4. Add unit coverage for a report with type: CONST.REPORT.TYPE.TASK, chatType: CONST.REPORT.CHAT_TYPE.POLICY_ADMINS, and a stale errorFields.notFound. Assert that the details guard allows the loaded task report, isTaskReport(report) is true, room helpers return false, and shouldDisableDetailPage(report) remains false.

Scope boundaries: src/pages/inbox/report/withReportOrNotFound.tsx or src/libs/ReportUtils.ts for the loaded-task access guard; src/libs/ReportUtils.ts for the room-helper task guards; optional test-only changes under tests/unit/ReportUtilsTest or the existing report details guard tests. This affects all clients through shared JS. It should not change buildOptimisticTaskReport(), OpenReport API parameters, backend task creation, or header navigation.

What alternative solutions did you explore? (Optional)

MelvinBot correctly identified the ReportScreen vs withReportOrNotFound guard asymmetry, but only changing that guard would still leave admins-room task reports classified as rooms and would still expose room UI on the task details page.

My earlier proposal covered the inherited chatType room-classification problem, but that alone would not explain or fix the NotFound gate because withReportOrNotFound() still rejects reports with errorFields.notFound.

I also considered removing chatType from admins-room task reports, but that would reintroduce the FE/BE mismatch fixed by #84258. Keeping the field and making task identity override room helpers is narrower.

[melvin-bot]

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

[melvin-bot]

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

[KJ21-ENG]

Updated my proposal - split the fix into the task-details access guard and inherited #admins chatType room classification.

[yuvrajangadsingh]

Proposal

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

When a new user finishes onboarding as "Manage my team's expenses" and opens any task in the #admins room, tapping the report header navigates to the task's details page but shows "Hmm... it's not here" instead of the task details.

What is the root cause of that problem?

ReportFetchHandler.fetchReport has a guard that skips calling openReport for optimistic reports that don't exist server-side yet:

// src/pages/inbox/ReportFetchHandler.tsx
if (reportMetadata.isOptimisticReport && report?.type === CONST.REPORT.TYPE.CHAT && !isPolicyExpenseChat(report)) {
    return;
}

This guard was written for optimistic chat reports, but it only checks type === CHAT. Onboarding task reports created by prepareOnboardingOnyxData in ReportUtils.ts:11944-11947 are explicitly marked isOptimisticReport: true in their metadata, but their type is TASK, not CHAT. So the guard misses them.

When the user opens a task from the #admins room, fetchReport fires (via the useEffect at ReportFetchHandler.tsx:246-251 that runs on route changes). Since the guard doesn't match, openReport is called for the task. At this point CompleteGuidedSetup may not have finished creating the tasks server-side yet, so the server returns "not found". That response sets report.errorFields.notFound on the task in Onyx.

Then when the user taps the task header, HeaderView.tsx:314 calls navigateToDetailsPage(report), which routes to r/{taskReportID}/details. On that page, withReportOrNotFound.tsx:103 evaluates canAccessReport(report, betas, isReportArchived). In ReportUtils.ts:9062-9064, canAccessReport returns false because report.errorFields.notFound is set. withReportOrNotFound then renders NotFoundPage instead of the details content.

ReportNotFoundGuard on the task's report screen doesn't trip because it only checks !!reportID, never errorFields.notFound — so the user can view the task itself just fine. The asymmetry only surfaces when navigating to the details sub-page.

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

The fix is one line in src/pages/inbox/ReportFetchHandler.tsx. isTaskReport is already imported there, so extend the existing guard to also cover optimistic task reports:

// before
if (reportMetadata.isOptimisticReport && report?.type === CONST.REPORT.TYPE.CHAT && !isPolicyExpenseChat(report)) {

// after
if (reportMetadata.isOptimisticReport && (report?.type === CONST.REPORT.TYPE.CHAT || isTaskReport(report)) && !isPolicyExpenseChat(report)) {

This prevents openReport from firing while a task is still pending server-side creation, so errorFields.notFound is never written to Onyx. Once CompleteGuidedSetup succeeds, the success data at ReportUtils.ts:12030-12035 sets isOptimisticReport: false on the task's metadata. On the user's next navigation to that report, fetchReport runs again, the guard no longer applies, openReport succeeds (task is now server-side), and everything is consistent.

What alternative solutions did you explore? (Optional)

MelvinBot's proposal targets withReportOrNotFound — either skipping canAccessReport for task reports or treating the guards asymmetrically. That would hide real "not found" errors for future task-related pages. The human proposal targets isAdminRoom/isDefaultRoom to stop tasks from being classified as admin rooms. That analysis is off: for tasks with chatType: POLICY_ADMINS, canSeeDefaultRoom already returns true via its own isAdminRoom check, so that path in canAccessReport never blocks them. The issue is purely errorFields.notFound, and the only safe fix is stopping the premature openReport call at source.

working branch with the fix applied: diff

[trasnake87]

Proposal

Tapping the report header of any onboarding task in the #admins room opens the "Hmm… it's not here" NotFoundPage instead of the task details page.

Root cause

This is a regression with three layered contributing factors.

1 - Onboarding #admins task reports inherit a room chatType:

buildOptimisticTaskReport stamps the POLICY_ADMINS chat type onto every onboarding task created in the #admins room:

// src/libs/ReportUtils.ts:8652-8666 (buildOptimisticTaskReport)
return {
    reportID: generateReportID(),
    ...
    type: CONST.REPORT.TYPE.TASK,
    // Only #admins tasks inherit chatType for Concierge routing.
    // Task reports are not expense chats, so we do not inherit policyExpenseChat (or other chat types).
    ...(parentChatType === CONST.REPORT.CHAT_TYPE.POLICY_ADMINS && {chatType: CONST.REPORT.CHAT_TYPE.POLICY_ADMINS}),
    parentReportID,
    ...
};

The chat type is deliberately kept for backend Concierge routing, but it makes the report simultaneously type: TASK and a room as far as every client predicate is concerned, because all of them key off chatType only:

// src/libs/ReportUtils.ts:1666-1668 / 1773-1775 / 1645-1647
function isDefaultRoom(report) { return CONST.DEFAULT_POLICY_ROOM_CHAT_TYPES.some((type) => type === getChatType(report)); }
function isChatRoom(report)    { return isUserCreatedPolicyRoom(report) || isDefaultRoom(report) || isInvoiceRoom(report) || isTripRoom(report); }
function isAdminRoom(report)   { return getChatType(report) === CONST.REPORT.CHAT_TYPE.POLICY_ADMINS; }

(DEFAULT_POLICY_ROOM_CHAT_TYPES includes POLICY_ADMINS — src/CONST/index.ts:208.)

2 - ReportDetailsPage and ReportScreen disagree on "not found":

ReportScreen guards with ReportNotFoundGuard, which only checks that the report exists in Onyx — it never consults errorFields.notFound:

// src/pages/inbox/ReportNotFoundGuard.tsx:51-53
const reportExists = !!reportID || isOptimisticDelete || userLeavingStatus;
const shouldShowNotFoundPage = !deleteTransactionNavigateBackUrl && (isInvalidReportPath || (!isLoading && !reportExists));

So the task opens and renders fine in the report view. ReportDetailsPage is instead wrapped by withReportOrNotFound(), which routes through canAccessReport:

// src/pages/inbox/report/withReportOrNotFound.tsx:103
const shouldShowNotFoundPage = !isReportLoaded || !canAccessReport(report, betas, isReportArchived);

// src/libs/ReportUtils.ts:9055-9066
function canAccessReport(report, betas, isReportArchived = false) {
    if (isDefaultRoom(report) && !canSeeDefaultRoom(report, betas, isReportArchived)) {
        return false;
    }
    if (report?.errorFields?.notFound) {
        return false;
    }
    return true;
}

The default-room branch does not fire (canSeeDefaultRoom returns true via the isAdminRoom short-circuit at src/libs/ReportUtils.ts:9047, since the task carries the POLICY_ADMINS chat type). The 404 therefore comes from the second branch: the server transiently attaches errorFields.notFound to these reports while CompleteGuidedSetup reconciles the optimistic task — the backend applies its POLICY_ADMINS room access check (the report carries that chat type) to a brand-new account whose policy-admin status is not yet established. The frontend never sets notFound truthy itself — it only ever clears it to null (src/libs/actions/Report/index.ts:1526,1940), so this value is purely server-driven. Net result: ReportScreen shows the task, but tapping the header → navigateToDetailsPage (src/libs/ReportUtils.ts:6120-6133) → ReportDetailsPage → canAccessReport returns false → NotFoundPage.

3 - The same misclassification would wrongly render a Room description field:

Once the page opens, the inherited chat type makes the task look like a room here:

// src/pages/ReportDetailsPage.tsx:222
const shouldShowReportDescription = isChatRoom && (canEditReportDescription || report.description !== '') && (isTaskReport ? isTaskModifiable : true);

isChatRoom is true (chat type), onboarding tasks always carry a description, and onboarding tasks are modifiable, so the Room description row renders — exactly what the Expected Result calls out ("there is no Room description field").

Proposed fix

Two targeted, type-guarded changes. A type: TASK report must never be 404'd by the report-level errorFields.notFound, nor be treated as a room in the details UI. A task's genuine deletion is surfaced through its parent report action / isCanceledTaskReport (src/pages/ReportDetailsPage.tsx:217,301-308), not this server field, and withReportOrNotFound still 404s a truly missing task via its !isReportLoaded check.

// src/libs/ReportUtils.ts — canAccessReport (replace lines 9055-9066)
function canAccessReport(report: OnyxEntry<Report>, betas: OnyxEntry<Beta[]>, isReportArchived = false): boolean {
    // We hide default rooms (it's basically just domain rooms now) from people who aren't on the defaultRooms beta.
    if (isDefaultRoom(report) && !canSeeDefaultRoom(report, betas, isReportArchived)) {
        return false;
    }

    // Onboarding tasks posted to #admins inherit the POLICY_ADMINS chatType purely for backend
    // Concierge routing (see buildOptimisticTaskReport). They are still `type: TASK`; the server
    // transiently flags them with errorFields.notFound for brand-new accounts before
    // CompleteGuidedSetup reconciles. ReportScreen still renders them (ReportNotFoundGuard only
    // checks existence), so the details page must not diverge. A genuinely deleted task is
    // surfaced via its parent report action (isCanceledTaskReport), not report-level notFound.
    if (report?.errorFields?.notFound && !isTaskReport(report)) {
        return false;
    }

    return true;
}

// src/pages/ReportDetailsPage.tsx:222 — never show the Room description row for a task
const shouldShowReportDescription = isChatRoom && !isTaskReport && (canEditReportDescription || report.description !== '');

isTaskReport is defined in src/libs/ReportUtils.ts:1519-1521 (in scope for canAccessReport) and the memoized isTaskReport already exists in ReportDetailsPage.tsx:214, so no new imports are required.

Why this approach

The 404 is fixed at the single shared chokepoint: canAccessReport is also consumed by withReportAndReportActionOrNotFound.tsx:78 and canCurrentUserOpenReport (src/libs/ReportUtils.ts:10738), so a task-aware guard keeps every report-detail entry point consistent with ReportScreen — the existing precedent that "a report that exists should not 404". The notFound behaviour is preserved verbatim for every non-task report, so there is zero blast radius for rooms and chats. The ReportDetailsPage change mirrors the team's existing intent on the very same line (the isTaskReport ? … : … special-case already acknowledges a task can carry a chat type) and satisfies the Expected Result. Removing the chatType in buildOptimisticTaskReport was considered and rejected: the comment there documents it as required for backend Concierge routing, so the correct fix is to stop the client treating a task as a room, not to strip the routing hint.

[abbasifaizan70]

Proposal

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

For a fresh "Manage my team's expenses" onboarding account (size 11–50 + SAP integration, on iOS), opening any onboarding task posted to the #admins room and tapping the task report header navigates to the generic "Hmm… it's not here" page instead of the task's Details page.

The Expected Result has two parts: the Details page should actually open for the task report, and it should not render a "Room description" field (Room description is a room concept; tasks have their own title/description flow). Right now the user is blocked on the NotFoundPage, so the Room-description part of the expectation never even gets a chance to render correctly.

What is the root cause of that problem?

The bug is the combination of two assumptions in the client that overlap badly on onboarding admins-room task reports. Both have to be fixed; otherwise even if we get past the NotFoundPage the Details page would still render a Room description row for a task.

Defect 1 — ReportScreen and ReportDetailsPage disagree about what "not found" means

The main report screen is gated by ReportNotFoundGuard. It only considers a report missing when it does not exist in Onyx after loading, and it never inspects report.errorFields.notFound:

App/src/pages/inbox/ReportNotFoundGuard.tsx

Lines 51 to 53 in 45f992d

	const reportExists = !!reportID || isOptimisticDelete || userLeavingStatus;
	const shouldShowNotFoundPage = !deleteTransactionNavigateBackUrl && (isInvalidReportPath || (!isLoading && !reportExists));

The Details page is wrapped by withReportOrNotFound() instead, and that wrapper feeds the loaded report through the stricter canAccessReport predicate:

App/src/pages/inbox/report/withReportOrNotFound.tsx

Lines 101 to 103 in 45f992d

	if (shouldRequireReportID || isReportIdInRoute) {
	const shouldShowFullScreenLoadingIndicator = !isReportLoaded && (isLoadingReportData !== false || shouldFetchReport);
	const shouldShowNotFoundPage = !isReportLoaded || !canAccessReport(report, betas, isReportArchived);

canAccessReport rejects any report whose Onyx record carries a truthy errorFields.notFound, which is exactly the divergence from ReportNotFoundGuard:

App/src/libs/ReportUtils.ts

Lines 9044 to 9055 in 45f992d

	function canAccessReport(report: OnyxEntry<Report>, betas: OnyxEntry<Beta[]>, isReportArchived = false): boolean {
	// We hide default rooms (it's basically just domain rooms now) from people who aren't on the defaultRooms beta.
	if (isDefaultRoom(report) && !canSeeDefaultRoom(report, betas, isReportArchived)) {
	return false;
	}
	if (report?.errorFields?.notFound) {
	return false;
	}
	return true;
	}

How errorFields.notFound ends up on an onboarding task: prepareOnboardingOnyxData creates each onboarding task optimistically and tags the report metadata with isOptimisticReport: true:

App/src/libs/ReportUtils.ts

Lines 11947 to 11952 in 45f992d

	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_METADATA}${currentTask.reportID}`,
	value: {
	isOptimisticReport: true,
	},
	},

ReportFetchHandler then runs fetchReport() on every route change, and its early-return guard for optimistic reports only matches type === CHAT, so tasks (which are type: TASK) fall through and openReport fires for them while CompleteGuidedSetup is still reconciling them server-side:

App/src/pages/inbox/ReportFetchHandler.tsx

Lines 118 to 142 in 45f992d

	const fetchReport = useEffectEvent(() => {
	if (reportMetadata.isOptimisticReport && report?.type === CONST.REPORT.TYPE.CHAT && !isPolicyExpenseChat(report)) {
	return;
	}
	if (report?.errorFields?.notFound && isOffline) {
	return;
	}
	// When a user goes through onboarding for the first time, various tasks are created for chatting with Concierge.
	// If this function is called too early (while the application is still loading), we will not have information about policies,
	// which means we will not be able to obtain the correct link for one of the tasks.
	// More information here: https://github.com/Expensify/App/issues/71742
	if (isLoadingApp && introSelected && !isOnboardingCompleted && !isInviteOnboardingComplete) {
	const {choice, inviteType} = introSelected;
	const isInviteIOUorInvoice = inviteType === CONST.ONBOARDING_INVITE_TYPES.IOU || inviteType === CONST.ONBOARDING_INVITE_TYPES.INVOICE;
	const isInviteChoiceCorrect = choice === CONST.ONBOARDING_CHOICES.ADMIN || choice === CONST.ONBOARDING_CHOICES.SUBMIT || choice === CONST.ONBOARDING_CHOICES.CHAT_SPLIT;
	if (isInviteChoiceCorrect && !isInviteIOUorInvoice) {
	return;
	}
	}
	openReport({reportID: reportIDFromRoute, introSelected, reportActionID: reportActionIDFromRoute, betas});
	});

The frontend only ever clears notFound (the success branch sets it to null on success); it never sets it truthy. So the truthy value is purely server-driven, written by the OpenReport response, and it lives on the Onyx report until the next successful openReport:

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

Lines 1521 to 1529 in 45f992d

	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value: {
	errorFields: {
	notFound: null,
	},
	},
	},

End-to-end: ReportScreen still renders the task fine (its guard only checks existence). Tapping the header calls navigateToDetailsPage(report) on the task and routes to r/{taskID}/details:

App/src/pages/inbox/HeaderView.tsx

Lines 312 to 320 in 45f992d

	<View style={[styles.flex1, styles.flexRow, styles.alignItemsCenter, styles.justifyContentBetween]}>
	<PressableWithoutFeedback
	onPress={() => navigateToDetailsPage(report, Navigation.getReportRHPActiveRoute(), true)}
	style={[styles.flexRow, styles.alignItemsCenter, styles.flex1]}
	disabled={shouldDisableDetailPage}
	accessibilityLabel={title}
	role={CONST.ROLE.BUTTON}
	sentryLabel={CONST.SENTRY_LABEL.HEADER_VIEW.DETAILS_BUTTON}
	>

App/src/libs/ReportUtils.ts

Lines 6109 to 6122 in 45f992d

	function navigateToDetailsPage(report: OnyxEntry<Report>, backTo?: string, shouldUseActiveRoute?: boolean) {
	const isSelfDMReport = isSelfDM(report);
	const isOneOnOneChatReport = isOneOnOneChat(report);
	const participantAccountID = getParticipantsAccountIDsForDisplay(report);
	if (isSelfDMReport || isOneOnOneChatReport) {
	Navigation.navigate(ROUTES.PROFILE.getRoute(participantAccountID.at(0), isSelfDMReport || shouldUseActiveRoute ? Navigation.getActiveRoute() : backTo));
	return;
	}
	if (report?.reportID) {
	Navigation.navigate(ROUTES.REPORT_WITH_ID_DETAILS.getRoute(report?.reportID, backTo));
	}
	}

At that point withReportOrNotFound calls canAccessReport, the errorFields.notFound branch fires, and NotFoundPage is rendered. The first branch of canAccessReport (default-room beta) does not fire here even though the task carries chatType: POLICY_ADMINS, because canSeeDefaultRoom short-circuits to true for admin rooms — the 404 strictly comes from the errorFields.notFound branch.

Defect 2 — Admins-room task reports inherit a room chatType, so room helpers misclassify them

buildOptimisticTaskReport deliberately copies chatType: POLICY_ADMINS onto the task when the parent is the #admins room. This is required so the backend routes Concierge messaging correctly (PR #84258), but it makes the report simultaneously type: TASK and a room as far as every client predicate is concerned:

App/src/libs/ReportUtils.ts

Lines 8641 to 8659 in 45f992d

	return {
	reportID: generateReportID(),
	created: DateUtils.getDBTime(),
	reportName: getParsedComment(title ?? '', undefined, undefined, [...CONST.TASK_TITLE_DISABLED_RULES]),
	description: getParsedComment(description ?? '', {}),
	ownerAccountID,
	participants,
	managerID: assigneeAccountID,
	type: CONST.REPORT.TYPE.TASK,
	// Only #admins tasks inherit chatType for Concierge routing.
	// Task reports are not expense chats, so we do not inherit policyExpenseChat (or other chat types).
	...(parentChatType === CONST.REPORT.CHAT_TYPE.POLICY_ADMINS && {chatType: CONST.REPORT.CHAT_TYPE.POLICY_ADMINS}),
	parentReportID,
	policyID,
	stateNum: CONST.REPORT.STATE_NUM.OPEN,
	statusNum: CONST.REPORT.STATUS_NUM.OPEN,
	lastVisibleActionCreated: DateUtils.getDBTime(),
	hasParentAccess: true,
	};

Every room helper keys off chatType only, so isAdminRoom, isDefaultRoom, and therefore isChatRoom all return true for an admins-room task:

App/src/libs/ReportUtils.ts

Lines 1642 to 1664 in 45f992d

	function isAdminRoom(report: OnyxEntry<Report>): boolean {
	return getChatType(report) === CONST.REPORT.CHAT_TYPE.POLICY_ADMINS;
	}
	/**
	* Whether the provided report is an Admin-only posting room
	*/
	function isAdminsOnlyPostingRoom(report: OnyxEntry<Report>): boolean {
	return report?.writeCapability === CONST.REPORT.WRITE_CAPABILITIES.ADMINS;
	}
	/**
	* Whether the provided report is a Announce room
	*/
	function isAnnounceRoom(report: OnyxEntry<Report>): boolean {
	return getChatType(report) === CONST.REPORT.CHAT_TYPE.POLICY_ANNOUNCE;
	}
	/**
	* Whether the provided report is a default room
	*/
	function isDefaultRoom(report: OnyxEntry<Report>): boolean {
	return CONST.DEFAULT_POLICY_ROOM_CHAT_TYPES.some((type) => type === getChatType(report));

App/src/libs/ReportUtils.ts

Lines 1770 to 1772 in 45f992d

	function isChatRoom(report: OnyxEntry<Report>): boolean {
	return isUserCreatedPolicyRoom(report) || isDefaultRoom(report) || isInvoiceRoom(report) || isTripRoom(report);
	}

Once the Details page is allowed to render, that misclassification produces the unwanted Room description row. isChatRoom is true (the inherited chatType), the onboarding task always carries a non-empty description, and the user can modify their own onboarding tasks, so the condition resolves truthy:

App/src/pages/ReportDetailsPage.tsx

Lines 221 to 222 in 45f992d

	const canEditReportDescription = useMemo(() => canEditReportDescriptionUtil(report, policy), [report, policy]);
	const shouldShowReportDescription = isChatRoom && (canEditReportDescription || report.description !== '') && (isTaskReport ? isTaskModifiable : true);

Defect 1 by itself causes the "Hmm… it's not here" page. Defect 2 by itself would still show a wrong Room description field on the task's Details page. Both need to be fixed for the Expected Result to hold.

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

Two type-guarded changes. The first one is in a shared chokepoint (canAccessReport) so every report-detail entry point — withReportOrNotFound, withReportAndReportActionOrNotFound, canCurrentUserOpenReport, shouldReportBeInOptionList — gets the same treatment and lines up with ReportScreen. The second is the existing precedent on the same line in ReportDetailsPage, tightened from "task-modifiable" to plainly "not a task".

A task's genuine deletion is already surfaced separately, via its parent report action (isCanceledTaskReport), and a truly missing report is still 404'd by withReportOrNotFound's !isReportLoaded check, so skipping the errorFields.notFound branch for task reports specifically is safe — it only changes behavior for the bug we want to fix.

In src/libs/ReportUtils.ts, replacing the errorFields.notFound branch of canAccessReport:

App/src/libs/ReportUtils.ts

Lines 9044 to 9055 in 45f992d

	function canAccessReport(report: OnyxEntry<Report>, betas: OnyxEntry<Beta[]>, isReportArchived = false): boolean {
	// We hide default rooms (it's basically just domain rooms now) from people who aren't on the defaultRooms beta.
	if (isDefaultRoom(report) && !canSeeDefaultRoom(report, betas, isReportArchived)) {
	return false;
	}
	if (report?.errorFields?.notFound) {
	return false;
	}
	return true;
	}

    if (report?.errorFields?.notFound && !isTaskReport(report)) {
        return false;
    }

In src/pages/ReportDetailsPage.tsx, replacing the shouldShowReportDescription expression so a task report never renders the Room description row regardless of inherited chatType:

App/src/pages/ReportDetailsPage.tsx

Lines 221 to 222 in 45f992d

	const canEditReportDescription = useMemo(() => canEditReportDescriptionUtil(report, policy), [report, policy]);
	const shouldShowReportDescription = isChatRoom && (canEditReportDescription || report.description !== '') && (isTaskReport ? isTaskModifiable : true);

    const shouldShowReportDescription = isChatRoom && !isTaskReport && (canEditReportDescription || report.description !== '');

isTaskReport is defined at src/libs/ReportUtils.ts:1516-1518 so it is in scope where canAccessReport lives, and the memoized isTaskReport already exists at src/pages/ReportDetailsPage.tsx:214, so neither change introduces new imports.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

Add a unit test for a synthetic report with type: CONST.REPORT.TYPE.TASK, chatType: CONST.REPORT.CHAT_TYPE.POLICY_ADMINS, and errorFields.notFound: 'reportNotFound' set, asserting:

• canAccessReport(report, betas, false) returns true.
• canAccessReport({...report, type: CONST.REPORT.TYPE.CHAT}, betas, false) still returns false (existing behaviour for non-task reports is preserved).
• The shouldShowReportDescription expression derived from ReportDetailsPage (isChatRoom && !isTaskReport && (canEditReportDescription || report.description !== '')) resolves to false for that task fixture.