You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Due for payment 2026-07-29] Expense - Posted date is truncated #94526
Version Number: 9.4.19-1 Reproducible in staging?: Yes Reproducible in production?: N/A - new feature, doesn't exist in prod If this was caught during regression testing, add the test name, ID and link from BrowserStack:#94124 Email or phone of affected tester (no customers):applausetester+ssndjois2jd1@applause.expensifail.com Issue reported by: Applause Internal Team Bug source: Exploratory - Significant User Experience Deterioration Device used: Mac 26.5 / Chrome App Component: Money Requests
Action Performed:
Precondition:
Add a direct feed with card and assign a card with transactions to yourself on workspace settings > Company cards.
👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:
Identify the pull request that introduced this issue and revert it.
Please re-state the problem that we are trying to solve in this issue.
In a single report (workspace chat → open report → Columns → enable Posted → Save), the Posted date is truncated. Dates that include a year (e.g. Jan 5, 2024) get clipped instead of rendering fully.
What is the root cause of that problem?
PR #94124 newly enabled POSTED in the single‑report column picker (POSTED: {..., reportView: true} in COLUMN_AVAILABILITY), but the report‑view rendering path never computes or passes a postedColumnSize. As a result the Posted column is locked to its narrow width and past‑year dates overflow it.
Mechanism, verified end‑to‑end:
The Posted cell width is w92 (wide) only when isPostedColumnWide is true, otherwise w72 (narrow): src/styles/utils/index.ts:1908-1910. getWidthStyle sets a hard width (not minWidth), so content cannot expand the cell — it clips.
DateCell formats past‑year dates as MMM DD, YYYY with non‑wrapping styles.pre, so the wider string overflows the 72px box and is clipped: DateCell.tsx:27-35.
For comparison, the /search table works because it does pass postedColumnSize (from shouldShowYearPosted): TransactionListItemWide.tsx:124.
What changes do you think we should make in order to solve the problem?
Mirror the existing dateColumnSize wiring for Posted in the report‑view path:
In MoneyRequestReportTransactionList.tsx:568-577, compute a postedColumnSize by checking whether any transaction's posted date belongs to a past year (analogous to the existing shouldShowTransactionYear check used for dateColumnSize, but reading transaction.posted).
The prop already exists end‑to‑end (TransactionItemRow/types.ts:64, SortableTableHeader.tsx:98); only the report view's computation and pass‑through are missing.
What alternative solutions did you explore?
Simplest minimal fix: always pass postedColumnSize={CONST.SEARCH.TABLE_COLUMN_SIZES.WIDE} in the report view so Posted is unconditionally w92. This guarantees no truncation but widens the column even when no year is shown. The year‑detection approach above keeps the table compact and matches /search behavior, so it's preferred.
Confidence & verification
High confidence — static layout/prop‑threading bug, fully explained by source (no production logs needed). Two independent investigations converged on the same root cause, and the key lines (MoneyRequestReportTransactionList.tsx:568-577, styles/utils/index.ts:1908-1910, TransactionItemRowWide.tsx:221-233) were re‑verified directly. The fix is fully contained in the Expensify/App repo.
Next Steps for Contributor+ team: To accept:@MelvinBot implement [this](https://github.com/Expensify/App/issues/94526) to create a draft PR. To refine:@MelvinBot <your feedback> To reject: Explain why you are rejecting Melvin's proposal.
The solution for this issue has been 🚀 deployed to production 🚀 in version 9.4.41-4 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:
@mjasikowski@mukhrr The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]. If no checklist is needed for this issue, you can click: [no checklist button]
[Contributor] The offending PR and associated issue have been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake.
Link to the comment on the PR: No PR introduced this bug directly.
Link to the comment on the Issue:
[Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.
Link to discussion:
[Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.
[BugZero Assignee] Create a GH issue for creating/updating the regression test once above steps have been agreed upon.
Activity
applause-bot commentedon Jun 25, 2026
While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/50a4ad580e4932d9a1bce6b15f7d7869de26a4cbbf9f3169f5a35d8850f91f10
melvin-bot commentedon Jun 25, 2026
You have been assigned to this deploy blocker because you recently merged this PR: #94124
melvin-bot commentedon Jun 25, 2026
💬 A slack conversation has been started in #expensify-open-source
github-actions commentedon Jun 25, 2026
👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:
MelvinBot commentedon Jun 25, 2026
Proposal
Please re-state the problem that we are trying to solve in this issue.
In a single report (workspace chat → open report → Columns → enable Posted → Save), the Posted date is truncated. Dates that include a year (e.g.
Jan 5, 2024) get clipped instead of rendering fully.What is the root cause of that problem?
PR #94124 newly enabled
POSTEDin the single‑report column picker (POSTED: {..., reportView: true}inCOLUMN_AVAILABILITY), but the report‑view rendering path never computes or passes apostedColumnSize. As a result the Posted column is locked to its narrow width and past‑year dates overflow it.Mechanism, verified end‑to‑end:
w92(wide) only whenisPostedColumnWideis true, otherwisew72(narrow):src/styles/utils/index.ts:1908-1910.getWidthStylesets a hardwidth(notminWidth), so content cannot expand the cell — it clips.isPostedColumnWideis derived from thepostedColumnSizeprop:TransactionItemRowWide.tsx:131, used by the Posted cell atTransactionItemRowWide.tsx:221-233.amountColumnSize,dateColumnSize, andtaxAmountColumnSize— but notpostedColumnSize:MoneyRequestReportTransactionList.tsx:568-577. So it's never threaded throughMoneyRequestReportTransactionItem.tsx:206-208or the headerMoneyRequestReportTableHeader.tsx:84-86.postedColumnSizeis optional, so it arrivesundefined→isPostedColumnWide = false→ narroww72.DateCellformats past‑year dates asMMM DD, YYYYwith non‑wrappingstyles.pre, so the wider string overflows the 72px box and is clipped:DateCell.tsx:27-35.For comparison, the
/searchtable works because it does passpostedColumnSize(fromshouldShowYearPosted):TransactionListItemWide.tsx:124.What changes do you think we should make in order to solve the problem?
Mirror the existing
dateColumnSizewiring for Posted in the report‑view path:MoneyRequestReportTransactionList.tsx:568-577, compute apostedColumnSizeby checking whether any transaction's posted date belongs to a past year (analogous to the existingshouldShowTransactionYearcheck used fordateColumnSize, but readingtransaction.posted).postedColumnSizethroughMoneyRequestReportTransactionItem.tsx:206-208→TransactionItemRow, and intoMoneyRequestReportTableHeader.tsx:84-86→SortableTableHeaderso the header width matches.The prop already exists end‑to‑end (
TransactionItemRow/types.ts:64,SortableTableHeader.tsx:98); only the report view's computation and pass‑through are missing.What alternative solutions did you explore?
Simplest minimal fix: always pass
postedColumnSize={CONST.SEARCH.TABLE_COLUMN_SIZES.WIDE}in the report view so Posted is unconditionallyw92. This guarantees no truncation but widens the column even when no year is shown. The year‑detection approach above keeps the table compact and matches/searchbehavior, so it's preferred.Confidence & verification
High confidence — static layout/prop‑threading bug, fully explained by source (no production logs needed). Two independent investigations converged on the same root cause, and the key lines (
MoneyRequestReportTransactionList.tsx:568-577,styles/utils/index.ts:1908-1910,TransactionItemRowWide.tsx:221-233) were re‑verified directly. The fix is fully contained in theExpensify/Apprepo.Next Steps for Contributor+ team:
To accept:
@MelvinBot implement [this](https://github.com/Expensify/App/issues/94526)to create a draft PR.To refine:
@MelvinBot <your feedback>To reject: Explain why you are rejecting Melvin's proposal.
mukhrr commentedon Jun 25, 2026
I think this is pre-existing and is being handle here #93169 (comment)
#94124 only enabled Posted column cc @ahmedGaber93 @mjasikowski
mjasikowski commentedon Jun 25, 2026
Demoting this based on #94526 (comment)
33 remaining items
melvin-bot commentedon Jul 22, 2026
The solution for this issue has been 🚀 deployed to production 🚀 in version 9.4.41-4 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:
If no regressions arise, payment will be issued on 2026-07-29. 🎊
For reference, here are some details about the assignees on this issue:
melvin-bot commentedon Jul 22, 2026
@mjasikowski @mukhrr The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]. If no checklist is needed for this issue, you can click: [no checklist button]
melvin-bot commentedon Jul 27, 2026
@mukhrr Eep! 4 days overdue now. Issues have feelings too...
brunovjk commentedon Jul 27, 2026
Filling out the BZ Checklist ASAP.
brunovjk commentedon Jul 28, 2026
BugZero Checklist:
[Contributor] The offending PR and associated issue have been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake.
Link to the comment on the PR: No PR introduced this bug directly.
Link to the comment on the Issue:
[Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.
Link to discussion:
[Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.
[BugZero Assignee] Create a GH issue for creating/updating the regression test once above steps have been agreed upon.
Link to issue: https://github.com/Expensify/Expensify/issues/666576
Regression Test Proposal
Precondition:
Test:
Do we agree 👍 or 👎
Zapier Logs
Run ID: 00040eee-9f16-a7d1-0645-86bf68a4a484melvin-bot commentedon Jul 28, 2026
Triggered auto assignment to @mallenexpensify (
Awaiting Payment)melvin-bot commentedon Jul 28, 2026
Payment Summary
Upwork Job
BugZero Checklist (@mallenexpensify)
mallenexpensify commentedon Jul 30, 2026
Payment Summary
Contributor: @mukhrr due $250 via NewDot
Contributor+: @brunovjk due $250 via NewDot
^ Test case created. Thx
@mjasikowski I'm assuming they're due payment on this deploy blocker issue.
flaviadefaria commentedon Jul 31, 2026
Approved: @mukhrr paid $250 via NewDot
laurenreidexpensify commentedon Jul 31, 2026
$250 approved for @brunovjk