Fix offline expense details not displaying after IOU payment by MelvinBot · Pull Request #91623 · Expensify/App

MelvinBot · 2026-05-25T15:22:02Z

Explanation of Change

When paying an IOU offline (via "Pay with business account") and then opening the expense from the workspace chat, the expense detail view showed a loading skeleton with no expense details. On large screens with a new workspace, the expense showed "Not Found."

Three issues contributed to this:

"Not Found" on large screen + no workspace: createWorkspaceFromIOUPayment did not set parentReportID on the converted expense report to point to the new workspace chat. When navigating to the expense, getParentReportActionDeletionStatus looked up the parent action using the old DM chat (where it was nullified), concluding the action was deleted and showing "Not Found."
Loading skeleton (both workspace paths): ReportFetchHandler's transaction thread creation fallback was gated on hasOnceLoadedReportActions, which is only set true on API success — which never fires offline. Added isOffline awareness so the fallback can create the thread from locally available data when offline, following the same precedent as shouldWaitForTransactions in MoneyRequestReportUtils.ts.
Missing link for existing workspace path: convertIOUReportToExpenseReport cleared iouReportID on the old DM chat but never set it on the new policy expense chat, preventing the expense detail view from resolving the moved report.

Fixed Issues

$ #90692
PROPOSAL: #90692 (comment)

Tests

Same as QA

Offline tests

Same as QA

QA Steps

Pre condition:
Have 2 accounts: User A and User B

From user A send IOU to User B
Login to user B in a large screen device
Open the chat in User B account and go offline
In pay option choose "Pay with business account"
Navigate to the policy expense chat where IOU was moved
Open the expense, verify it's not in loading state
Turn on the internet and navigate to user A's DM
From user A account send another IOU to user B
Repeat steps 4-6
Repeat all the steps with user B logged in at a smaller screen

Verify that no errors appear in the JS console

PR Author Checklist

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

AI Tests

Check	Result
Prettier	Passed (no changes)
ESLint (`lint-changed`)	Passed (0 errors, pre-existing warnings only)
TypeScript (`typecheck-tsgo`)	Passed (pre-existing errors only, none related to changes)
React Compiler compliance	Passed
Jest unit tests	Running (large test suite)

When paying an IOU offline and then opening the expense from the workspace chat, the total showed as loading and no expense details were displayed. Three issues contributed: 1. createWorkspaceFromIOUPayment did not set parentReportID on the expense report to point to the new workspace chat, causing "Not Found" on large screens when the parent action lookup failed. 2. ReportFetchHandler's transaction thread creation guard blocked the offline fallback because hasOnceLoadedReportActions is only set on API success, which never fires offline. Added isOffline awareness so the thread can be created from locally available data. 3. convertIOUReportToExpenseReport did not set iouReportID on the new policy expense chat, preventing the expense detail view from resolving the report. Co-authored-by: Sahil <thesahindia@users.noreply.github.com>

codecov · 2026-05-25T15:31:11Z

Codecov Report

❌ Looks like you've decreased code coverage for some files. Please write tests to increase, or at least maintain, the existing level of code coverage. See our documentation here for how to interpret this table.

Files with missing lines	Coverage Δ
src/libs/actions/Policy/Policy.ts	`71.20% <100.00%> (-0.38%)`	⬇️
src/pages/inbox/ReportFetchHandler.tsx	`85.18% <50.00%> (ø)`
... and 329 files with indirect coverage changes

thesahindia · 2026-05-29T18:49:52Z

+    optimisticData.push({
+        onyxMethod: Onyx.METHOD.MERGE,
+        key: `${ONYXKEYS.COLLECTION.REPORT}${optimisticPolicyExpenseChatReportID}`,
+        value: {
+            iouReportID: reportID,
+            hasOutstandingChildRequest: !isReportManuallyReimbursed(iouReport),
+        },
+    });
+    failureData.push({
+        onyxMethod: Onyx.METHOD.MERGE,
+        key: `${ONYXKEYS.COLLECTION.REPORT}${optimisticPolicyExpenseChatReportID}`,
+        value: {
+            iouReportID: null,
+        },
+    });


@MelvinBot, could you explain the changes here? All the scenarios seems to be working fine even without adding this change. Why do we need it?

This block keeps the destination policy expense chat aware of the moved expense report. The previous block at Report/index.ts:6867-6882 clears iouReportID on the old DM chat (sets it to null), but without this addition the new policy expense chat never gets iouReportID set to point at the moved report — so the chat→IOU link is broken on both sides while the move is in flight offline.

Concretely, chatReport.iouReportID is read in many downstream places — money request creation in MoneyRequestBuilder.ts:1169-1170, pay flows in PayMoneyRequest.ts:530, sidebar metadata at SidebarUtils.ts:902, isIOUOwnedByCurrentUser at ReportUtils.ts:9000-9005, etc. hasOutstandingChildRequest also drives the green-dot (GBR) indicator on the chat.

Honest assessment of your observation: the two visible symptoms in #90692 (loading skeleton and "Not Found") are actually fixed by the other two files — ReportFetchHandler.tsx (the isOffline gate) and Policy.ts (the parentReportID set on the converted report). I added this block defensively for state consistency so downstream code that consults chatReport.iouReportID on the moved-to chat keeps working between the offline move and the server reconcile. If your testing of the reported scenarios passes without it, it's not load-bearing for those specific repro steps.

I also want to flag a real concern with the block as written: the failure rollback unconditionally sets iouReportID: null on the destination chat. In the existing workspace path (call site at Report/index.ts:6560), that chat may have had a prior iouReportID value pointing at a different active expense — and the rollback would clobber it. The new-workspace path is safe (the chat is freshly created), but the shared function is used by both.

Given that, I'd lean toward removing this block since you've verified the user-visible scenarios work without it, rather than fixing the rollback. Want me to drop it?

@MelvinBot, let's remove it.

Done — removed the block in 7e88101.

The optimisticData/failureData pushes that set iouReportID on the destination policy expense chat (previously at Report/index.ts:6884-6900) are gone. The two user-visible symptoms in the issue stay fixed by the other two files (ReportFetchHandler.tsx isOffline gate + Policy.ts parentReportID), and dropping this also avoids the rollback clobbering a pre-existing iouReportID on the shared existing-workspace path.

Checks run on this change

Check Result

Prettier Passed (no changes)

ESLint Passed

TypeScript (typecheck-tsgo) Passed (pre-existing unrelated errors only)

Jest wasn't re-run in this environment, but the convertIOUReportToExpenseReport unit tests only assert on the moved report's reportName — they don't reference the removed destination-chat iouReportID block, so this pure deletion doesn't affect them.

thesahindia · 2026-05-30T17:40:26Z

@MelvinBot, when the user pays with workspace offline for the first time the moved expense in policy expense chat has IOU written on it and when you navigate inside it shows IOU in header.

When createWorkspaceFromIOUPayment runs offline (user pays the first time with workspace), the moved report kept the stale reportName "IOU" because the optimistic update spread the existing iouReport without recomputing the name. Both the policy expense chat preview and the report header read the same reportName field, so both displayed "IOU". Mirror what convertIOUReportToExpenseReport already does: - Recompute reportName via computeOptimisticReportName(expenseReport, newWorkspace, policyID, transactionsRecord). - Set childReportName on the moved report-preview action so the chat preview fallback matches. Co-authored-by: Sahil <thesahindia@users.noreply.github.com>

MelvinBot · 2026-05-30T17:50:16Z

Fixed in 131b0ce.

Root cause: When createWorkspaceFromIOUPayment converts the IOU report to an expense report optimistically, it spreads iouReport and flips type to EXPENSE but never recomputes reportName. The backend stamps IOU reports with reportName: "IOU", and that stale value survived the merge. Both the header (HeaderView → getReportName) and the policy expense chat preview (MoneyRequestReportPreviewContent → getReportName) read the same field, so both rendered "IOU".

convertIOUReportToExpenseReport in Report/index.ts already handles this — createWorkspaceFromIOUPayment just wasn't mirroring it.

Fix: In Policy.ts:

Compute expenseReport.reportName via ReportUtils.computeOptimisticReportName(expenseReport, newWorkspace, policyID, transactionsRecord).
Set childReportName: expenseReport.reportName on the moved reportPreviewAction optimistic update so the chat preview fallback matches.

thesahindia · 2026-05-30T22:11:02Z

Root cause: When createWorkspaceFromIOUPayment converts the IOU report to an expense report optimistically, it spreads iouReport and flips type to EXPENSE but never recomputes reportName. The backend stamps IOU reports with reportName: "IOU", and that stale value survived the merge. Both the header (HeaderView → getReportName) and the policy expense chat preview (MoneyRequestReportPreviewContent → getReportName) read the same field, so both rendered "IOU".

@MelvinBot, why does it only happens with the first IOU that get paid offline with a business account?

MelvinBot · 2026-05-30T22:12:57Z

Because "first payment with business account" is the only time the createWorkspaceFromIOUPayment path runs — every subsequent payment goes through a different function that already recomputes the name.

In BaseKYCWall.tsx:143-204:

If the user already has an admin workspace → it calls moveIOUReportToPolicyAndInviteSubmitter (or moveIOUReportToPolicy), which delegates to convertIOUReportToExpenseReport. That function already calls computeOptimisticReportName and assigns the result, so the name is correct.
If the user has no admin workspace yet → it falls through to createWorkspaceFromIOUPayment (the create-workspace-and-convert flow), which was missing that same step.

So the symptom is gated on "no admin workspace exists" — i.e. the first time a user pays an IOU with a business account, since that's also the moment the workspace is created. After that, the user has an admin workspace and the call routes through the already-correct convertIOUReportToExpenseReport path.

Online, the issue was masked because the backend response sent the correct reportName shortly after, overwriting the stale optimistic "IOU". Offline there's no response, so the stale name stayed visible.

thesahindia · 2026-05-31T15:09:11Z

@MelvinBot, your changes still hasn't fixed it only "IOU" got replaced with "New report"

The previous attempt called computeOptimisticReportName, but for the offline workspace-from-IOU flow the new policy isn't in Onyx yet, so getReportFieldsByPolicyID returned {} and the fallback was the literal "New report" (DEFAULT_EXPENSE_REPORT_NAME). Two changes: - Policy.ts: seed newWorkspace.fieldList with the default title field (pattern "{report:type} {report:startdate}"), mirroring buildPolicyData. Also pass that fieldList through onto the converted expense report so Report.fieldList is consistent with its policy. - ReportUtils.ts: when the Onyx-resolved fieldList is empty, fall back to the passed policy's fieldList. This makes computeOptimisticReportName usable from contexts that construct optimistic data before the policy exists in Onyx, without changing behavior for any existing caller. Co-authored-by: Sahil <thesahindia@users.noreply.github.com>

MelvinBot · 2026-05-31T15:19:19Z

Fixed in 304f5e4.

Why "New report" appeared: computeOptimisticReportName resolves the title field via getReportFieldsByPolicyID(policyID), which reads from Onyx. The new workspace isn't in Onyx yet at the moment we build the optimistic data, so the lookup returned {} → titleReportField was undefined → it fell back to CONST.REPORT.DEFAULT_EXPENSE_REPORT_NAME ("New report").

Fix:

Policy.ts: seed newWorkspace.fieldList with the default title field (pattern {report:type} {report:startdate}), mirroring what buildPolicyData already does for the normal workspace-creation flow. Also propagate that fieldList onto the converted expense report.
ReportUtils.ts: when the Onyx-resolved fieldList is empty, fall back to the passed policy.fieldList. This makes computeOptimisticReportName work from callers that construct optimistic data before the policy is written to Onyx; existing callers (which pass policies already in Onyx) are unaffected.

The header and chat preview should now display something like "Expense 2026-05-31".

…eportToExpenseReport Co-authored-by: Sahil <thesahindia@users.noreply.github.com>

thesahindia · 2026-06-02T18:10:36Z

@MelvinBot, merge main.

…nseDetailsAfterIouPay Co-authored-by: Sahil <thesahindia@users.noreply.github.com>

MelvinBot · 2026-06-02T18:22:16Z

Merged main into the branch via git merge (no conflicts) and pushed e625f3b. The branch is now up to date with main.

MelvinBot · 2026-06-02T18:22:56Z

⚠️ MelvinBot CI Fix Loop Detected

MelvinBot has made 5 consecutive commits trying to fix CI failures. Automatic CI fix dispatches are now paused for this PR.

Next steps: A human should review the recent commits and resolve the conflicting CI errors manually.

thesahindia · 2026-06-03T06:45:40Z

Pre condition:
Have 2 accounts: User A and User B

From user A send IOU to User B
Login to user B in a large screen device
Open the chat in User B account and go offline
In pay option choose "Pay with business account"
Navigate to the policy expense chat where IOU was moved
Open the expense, verify it's not in loading state
Turn on the internet and navigate to user A's DM
From user A account send another IOU to user B
Repeat steps 4-6
Repeat all the steps with user B logged in at a smaller screen

@MelvinBot add these steps to QA Steps and put "Same as QA" in Tests and offline Tests section. Mark off all the items in the author checklist. I have verified it but I don't have the access to edit.

MelvinBot · 2026-06-03T06:47:57Z

Done, @thesahindia. I've updated the PR description:

QA Steps: added the steps you provided (kept the JS console check at the end)
Tests and Offline tests: set to "Same as QA"
PR Author Checklist: all items checked off per your verification

thesahindia · 2026-06-03T06:53:53Z

@MelvinBot mark PR as ready for review.

MelvinBot · 2026-06-03T06:55:22Z

Done, @thesahindia — marked this PR as ready for review.

melvin-bot · 2026-06-03T06:55:23Z

@thesahindia Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

thesahindia · 2026-06-06T16:18:31Z

@Gonals, could you please rerun the tests?

Gonals · 2026-06-09T10:04:23Z

There are some conflicts. Can you fix them?
Any commit will rerun the tests too

thesahindia · 2026-06-09T11:39:52Z

@MelvinBot merge main and resolve conflicts

…nseDetailsAfterIouPay Co-authored-by: Sahil <thesahindia@users.noreply.github.com> # Conflicts: # src/libs/ReportUtils.ts

MelvinBot · 2026-06-09T11:57:38Z

🤖 Merged main and resolved the conflict.

Conflict: One conflict in src/libs/ReportUtils.ts:6746 inside computeOptimisticReportName.

Resolution: Took main's version. On main, getReportFieldsByPolicyID was refactored to accept the policy object directly and read policy.fieldList (instead of looking it up from Onyx by policyID). That refactor already provides the exact fallback this PR added, so the PR's explicit reportFieldsFromOnyx / policy?.fieldList branch became redundant:

const titleReportField = getTitleReportField(getReportFieldsByPolicyID(policy) ?? {});

The offline IOU fix is preserved through the Policy.ts changes — createWorkspaceFromIOUPayment seeds newWorkspace.fieldList via buildDefaultTitleFieldList() and passes newWorkspace as the policy argument, which getReportFieldsByPolicyID(policy) now reads directly.

The other two files (Policy.ts, ReportFetchHandler.tsx) auto-merged cleanly. Please re-verify the offline flow before merge.

MelvinBot · 2026-06-09T12:10:16Z

⏱️ Ran out of time before I could finish. This usually means the task was too complex or I got stuck exploring. Please try again with a more specific request or post in #melvinbot-ai.

Run details

thesahindia · 2026-06-10T12:19:41Z

@MelvinBot pull main

…nseDetailsAfterIouPay Co-authored-by: Sahil <thesahindia@users.noreply.github.com>

MelvinBot · 2026-06-10T12:26:25Z

🤖 Merged latest main into this branch (no conflicts) and pushed.

thesahindia · 2026-06-15T11:18:12Z

@MelvinBot pull main

…nseDetailsAfterIouPay Co-authored-by: Sahil <thesahindia@users.noreply.github.com>

MelvinBot · 2026-06-15T11:24:49Z

🤖 Merged latest main into this branch (clean merge, no conflicts) and pushed.

MelvinBot · 2026-06-15T11:48:46Z

⏱️ Ran out of time before I could finish. This usually means the task was too complex or I got stuck exploring. Please try again with a more specific request or post in #melvinbot-ai.

Run details

Gonals · 2026-06-15T14:08:11Z

Still failing

thesahindia · 2026-06-17T18:44:39Z

@MelvinBot ESLint check is failing.

…rtion buildDefaultTitleFieldList added a 9th @typescript-eslint/no-unsafe-type-assertion violation (via `as unknown as Policy['fieldList']`), exceeding the grandfathered limit of 8 for Policy.ts. Build a complete PolicyReportField so the value is assignable without any assertion. Co-authored-by: Sahil <thesahindia@users.noreply.github.com>

MelvinBot · 2026-06-17T18:59:58Z

Fixed the failing ESLint check.

Cause: buildDefaultTitleFieldList introduced a 9th @typescript-eslint/no-unsafe-type-assertion violation in Policy.ts via as unknown as Policy['fieldList']. eslint-seatbelt grandfathers only 8 for this file, so the new assertion turned the whole rule from warnings into errors (9 problems).

Fix: The assertion existed only because the title-field object omitted required PolicyReportField properties. I now build a complete field (orderWeight, values, keys, externalIDs, disabledOptions, isTax) so the value is assignable to Policy['fieldList'] without any cast. This keeps the seatbelt count at 8 rather than loosening the baseline to 9.

Verified locally: lint passes with no errors and typecheck-tsgo reports no errors in the changed files.

thesahindia · 2026-06-17T19:06:48Z

@Gonals, the author checklist is complete, but the error doesn't seem to be going away.

MelvinBot · 2026-06-17T19:15:05Z

⏱️ Ran out of time before I could finish. This usually means the task was too complex or I got stuck exploring. Please try again with a more specific request or post in #melvinbot-ai.

Run details

github-actions · 2026-06-18T15:35:41Z

🚧 @Gonals has triggered a test Expensify/App build. You can view the workflow run here.

OSBotify · 2026-06-18T15:39:33Z

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

github-actions · 2026-06-18T15:43:36Z

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #91623.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-3cb396da029-3ab817a-73851c4247a4cc878b0b1af9a45bc51773bc1db1/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-3cb396d-3ab817a-908deef258ee3ab1f74ccd85b54b45e4113a774f/index.html

Web 🕸️
https://91623.pr-testing.expensify.com

👀 View the workflow run that generated this build 👀

OSBotify · 2026-06-18T17:17:22Z

🚀 Deployed to staging by https://github.com/Gonals in version: 9.4.15-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	cancelled 🔪
🍎 iOS 🍎	cancelled 🔪

MelvinBot · 2026-06-18T17:20:17Z

🤖 Help site review — no docs changes required

I reviewed the changes in this PR and no updates to Expensify's help site files under docs/articles are needed.

Why: This is a bug fix to internal state-handling logic only — both touched files (src/libs/actions/Policy/Policy.ts and src/pages/inbox/ReportFetchHandler.tsx) fix optimistic data / report-linking and offline transaction-thread creation. The change:

Introduces no new feature, page, setting, button, or copy.
Does not alter any user-facing workflow — it restores the expected behavior (expense details rendering instead of a loading skeleton or "Not Found") when paying an IOU offline via "Pay with business account."

Help articles describe how to pay expenses with a business account (e.g. Pay-Expenses.md); they do not document internal loading/error states, so there's nothing to add or correct.

No draft docs PR was created.

@thesahindia, if you believe a help-site change is warranted here, let me know and I'll create the draft PR.

OSBotify · 2026-06-19T15:23:14Z

🚀 Deployed to production by https://github.com/puneetlath in version: 9.4.15-3 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

MelvinBot assigned thesahindia May 25, 2026

MelvinBot requested a review from a team May 25, 2026 15:22

MelvinBot mentioned this pull request May 25, 2026

[Due for payment 2026-06-26] [$250] Expense - IOU is shown in preview & total is shown as loading,no expense details displayed #90692

Open

7 tasks

thesahindia reviewed May 29, 2026

View reviewed changes

Remove defensive iouReportID block on destination chat in convertIOUR…

7e88101

…eportToExpenseReport Co-authored-by: Sahil <thesahindia@users.noreply.github.com>

Merge remote-tracking branch 'origin/main' into claude-fixOfflineExpe…

e625f3b

…nseDetailsAfterIouPay Co-authored-by: Sahil <thesahindia@users.noreply.github.com>

MelvinBot marked this pull request as ready for review June 3, 2026 06:55

MelvinBot requested a review from a team as a code owner June 3, 2026 06:55

melvin-bot Bot requested a review from thesahindia June 3, 2026 06:55

melvin-bot Bot requested review from trjExpensify and removed request for a team June 3, 2026 06:55

thesahindia approved these changes Jun 6, 2026

View reviewed changes

Merge remote-tracking branch 'origin/main' into claude-fixOfflineExpe…

78aa8aa

…nseDetailsAfterIouPay Co-authored-by: Sahil <thesahindia@users.noreply.github.com> # Conflicts: # src/libs/ReportUtils.ts

Merge remote-tracking branch 'origin/main' into claude-fixOfflineExpe…

46a1e17

…nseDetailsAfterIouPay Co-authored-by: Sahil <thesahindia@users.noreply.github.com>

Merge remote-tracking branch 'origin/main' into claude-fixOfflineExpe…

bb7f154

…nseDetailsAfterIouPay Co-authored-by: Sahil <thesahindia@users.noreply.github.com>

Gonals approved these changes Jun 18, 2026

View reviewed changes

Gonals merged commit 3cb396d into main Jun 18, 2026
36 of 37 checks passed

Gonals deleted the claude-fixOfflineExpenseDetailsAfterIouPay branch June 18, 2026 15:33

OSBotify mentioned this pull request Jun 18, 2026

Deploy Checklist: New Expensify 2026-06-18 #93956

Closed

45 tasks

Check	Result
Prettier	Passed (no changes)
ESLint	Passed
TypeScript (`typecheck-tsgo`)	Passed (pre-existing unrelated errors only)

Uh oh!

Conversation

MelvinBot commented May 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Explanation of Change

Fixed Issues

Tests

Offline tests

QA Steps

PR Author Checklist

Screenshots/Videos

AI Tests

Uh oh!

codecov Bot commented May 25, 2026 • edited by github-actions Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

thesahindia May 29, 2026

Choose a reason for hiding this comment

Uh oh!

MelvinBot May 29, 2026

Choose a reason for hiding this comment

Uh oh!

thesahindia Jun 2, 2026

Choose a reason for hiding this comment

Uh oh!

MelvinBot Jun 2, 2026

Choose a reason for hiding this comment

Uh oh!

thesahindia commented May 30, 2026

Uh oh!

MelvinBot commented May 30, 2026

Uh oh!

thesahindia commented May 30, 2026

Uh oh!

MelvinBot commented May 30, 2026

Uh oh!

thesahindia commented May 31, 2026

Uh oh!

MelvinBot commented May 31, 2026

Uh oh!

thesahindia commented Jun 2, 2026

Uh oh!

MelvinBot commented Jun 2, 2026

Uh oh!

MelvinBot commented Jun 2, 2026

Uh oh!

thesahindia commented Jun 3, 2026

Uh oh!

MelvinBot commented Jun 3, 2026

Uh oh!

thesahindia commented Jun 3, 2026

Uh oh!

MelvinBot commented Jun 3, 2026

Uh oh!

melvin-bot Bot commented Jun 3, 2026

Uh oh!

thesahindia commented Jun 6, 2026

Uh oh!

Gonals commented Jun 9, 2026

Uh oh!

thesahindia commented Jun 9, 2026

Uh oh!

MelvinBot commented Jun 9, 2026

Uh oh!

MelvinBot commented Jun 9, 2026

Uh oh!

thesahindia commented Jun 10, 2026

Uh oh!

MelvinBot commented Jun 10, 2026

Uh oh!

thesahindia commented Jun 15, 2026

Uh oh!

MelvinBot commented Jun 15, 2026

Uh oh!

MelvinBot commented Jun 15, 2026

Uh oh!

Gonals commented Jun 15, 2026

Uh oh!

thesahindia commented Jun 17, 2026

MelvinBot commented May 25, 2026 •

edited

Loading

codecov Bot commented May 25, 2026 •

edited by github-actions Bot

Loading