fix - Report - Amount is not updated smoothly after deleting expenses from report. by FitseTLT · Pull Request #68484 · Expensify/App

FitseTLT · 2025-08-13T23:21:12Z

Details

Fixed Issues

$ #67641
PROPOSAL: #67641 (comment)

Tests

Prerequisite: Account has at least one workspace.

Open the expensify app.
Open any workspace chat.
Submit several manual expenses to with the same currency. (At least 5)
Open the report of the just created expenses.
Go offline
Select between two and three expenses.
Delete the selected expenses.
When deleting several expenses from a report, total amount should automatically change to the new correct total amount.

Verify that no errors appear in the JS console

Offline tests

Same as above

QA Steps

Same as above

Verify that no errors appear in the JS console

PR Author Checklist

Screenshots/Videos

Android: Native

2025-08-15.16-23-39.mp4

Android: mWeb Chrome

2025-08-15.17-55-31.mp4

iOS: mWeb Safari

2025-08-14.01-38-44.mp4

MacOS: Chrome / Safari

2025-08-14.01-37-29.mp4

MacOS: Desktop

2025-08-14.01-38-04.mp4

melvin-bot · 2025-08-13T23:21:18Z

@dukenv0307 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]

src/libs/actions/IOU.ts

dukenv0307 · 2025-08-14T09:01:41Z

src/libs/actions/IOU.ts

+        if (typeof updatedIOUReport.total === 'number' && currency === iouReport?.currency && canEditTotal) {
            // Because of the Expense reports are stored as negative values, we add the total from the amount
-            const amountDiff = getAmount(transaction, true);
+            const amountDiff = getAmount(transaction, true) + (transactionPendingDelete?.reduce((prev, curr) => prev + getAmount(curr, true), 0) ?? 0);


we can precompute the transactionAmounts (id: string, amount: number) before calling prepareToCleanUpMoneyRequest and reuse it

@dukenv0307 prepareToCleanUpMoneyRequest is handling the total updating logic inside it by considering the type of the iou report etc I don't think taking that logic out of the function is a good idea as a function should serve a single purpose if possible.

Don't you see that you've called getAmount too many times? And you also do it in the 2 nested loops, at least you can precompute them at the begining of prepareToCleanUpMoneyRequest

trjExpensify · 2025-08-19T21:56:39Z

My comments appear to be pending and I don't know why:

dukenv0307 · 2025-08-22T01:47:46Z

@FitseTLT Please let me know if it's ready for review. Thanks

dukenv0307 · 2025-08-26T02:46:11Z

Bump @FitseTLT

dukenv0307 · 2025-08-26T15:40:55Z

src/components/MoneyRequestReportView/MoneyRequestReportTransactionList.tsx

    const hasPendingAction = useMemo(() => {
-        return transactions.some(getTransactionPendingAction);
-    }, [transactions]);
+        return hasPendingDeletionTransaction || transactions.some(getTransactionPendingAction);


Can you please explain why we need this condition? Doesn't transactions.some(getTransactionPendingAction) cover pending delete?

@dukenv0307 we are already filtering out deleted transactions here

App/src/pages/home/ReportScreen.tsx

Line 306 in f54a2c1

const reportTransactions = useMemo(() => getAllNonDeletedTransactions(allReportTransactions, reportActions), [allReportTransactions, reportActions]);

but we just need to grey out only if the total can't be recalculated, right?

@trjExpensify is suggesting to follow the pattern we use for new expense creation and we grey it out until the BE clears the pending action currently, no matter the condition of the recalculation.

Sorry @FitseTLT, I'm still quite confused.

Based on the confirmation here, in offline mode, we want to grey out the amount only when the total can't be recalculated.

But with the current implementation, we always grey out even though the amount is updated (IOU currency is the same as expense currency)

@dukenv0307 I am trying to follow the current pattern we are using. On main, when adding a new expense with the same currency as the iou report it is greyed out even online until the BE response clears the pending field.

App/src/components/MoneyRequestReportView/MoneyRequestReportTransactionList.tsx

Lines 114 to 116 in f54a2c1

const hasPendingAction = useMemo(() => {

return transactions.some(getTransactionPendingAction);

}, [transactions]);

App/src/components/MoneyRequestReportView/MoneyRequestReportTotalSpend.tsx

Line 50 in f54a2c1

<Text style={[shouldUseNarrowLayout ? styles.mnw64p : styles.mnw100p, styles.textAlignRight, styles.textBold, hasPendingAction && styles.opacitySemiTransparent]}>

dukenv0307 · 2025-08-28T03:10:09Z

The amount remains greyed even when all API calls are successful

Screen.Recording.2025-08-28.at.10.04.14.mov

FitseTLT · 2025-08-28T13:40:50Z

The amount remains greyed even when all API calls are successful

Screen.Recording.2025-08-28.at.10.04.14.mov

This is caused by another RCA from useTransactionsAndViolationsForReport when we bulk delete transactions we have a logic here to update the derived values when a transaction is deleted (set to undefined)

App/src/libs/actions/OnyxDerived/configs/reportTransactionsAndViolations.ts

Lines 36 to 45 in da832dc

    
           const previousTransaction = previousTransactions?.[transactionKey]; 
        
           const previousReportID = previousTransaction?.reportID; 
        
           if (previousReportID && previousReportID !== reportID && reportTransactionsAndViolations[previousReportID]) { 
        
               delete reportTransactionsAndViolations[previousReportID].transactions[transactionKey]; 
        
               const transactionID = previousTransaction?.transactionID; 
        
               if (transactionID) { 
        
                   delete reportTransactionsAndViolations[previousReportID].violations[`${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${transactionID}`]; 
        
               } 
        
           }

to delete transactions because we can't get the previous reportID from a deleted transacion(undefined) we save the previousTransacion value that is set here

App/src/libs/actions/OnyxDerived/configs/reportTransactionsAndViolations.ts

Line 76 in da832dc

previousTransactions = transactions;

For our case when the first transaction is deleted transactionsToProcess will only include the first transaction although the transaction_ collection value includes the second deleted transaction set as undefined so our previousTransaction will not include the second transaction so when the second transaction is updated previousReportID will not be available and the logic to delete it from reportTransactionsAndViolations doesn't work.
Solution:

We can change the logic we are setting previousTransactions to only be set for the current sourceValue (changed keys) so that it doesn't get updated by the value of the next sourceValue like in our case.
We can solve reportTransactionsAndViolations logic to search and find previousReportID of a transaction by iterating on all keys of the record whenever we can't get previous value of the transaction from previousTransactions
We can calculate hasPendingDeletionTransaction with a new onyx subscription to a transaction collection and calculating it via selector

I prefer (1) WDYT @dukenv0307 ?

dukenv0307 · 2025-08-28T17:27:02Z

@FitseTLT Thanks for your response. Actually, the RCA is not clear to me

For our case when the first transaction is deleted transactionsToProcess will only include the first transaction

Why is that? Is it the issue with Onyx?

This is caused by another RCA from useTransactionsAndViolationsForReport

I agree with you, and I think we have 2 approaches now:

Do not update the hasPendingAction, just leave it as is because the grey out issue is out of scope (it also happens on main). Then create a new issue to handle it
Try to figure out the actual RCA and the solution

I think we should go with the first option. Please let me know what you think

FitseTLT · 2025-08-28T19:45:35Z

@FitseTLT Thanks for your response. Actually, the RCA is not clear to me

For our case when the first transaction is deleted transactionsToProcess will only include the first transaction

Why is that? Is it the issue with Onyx?

This is caused by another RCA from useTransactionsAndViolationsForReport

I agree with you, and I think we have 2 approaches now:

Do not update the hasPendingAction, just leave it as is because the grey out issue is out of scope (it also happens on main). Then create a new issue to handle it

Try to figure out the actual RCA and the solution

I think we should go with the first option. Please let me know what you think

I think we should go with (1) and handle it separately.

dukenv0307 · 2025-08-29T07:35:38Z

@trjExpensify What do you think: #68484 (comment)?

trjExpensify · 2025-08-30T14:39:36Z

The amount remains greyed even when all API calls are successful

Screen.Recording.2025-08-28.at.10.04.14.mov

This looks wrong to me. When you delete the expenses on the report while offline, they should display in the "pending delete" state from offline pattern B, meaning greyed out (50% opacity) and with strikethrough. In your video, they seem to completely disappear from the report.

dukenv0307 · 2025-09-01T01:58:40Z

@FitseTLT We're filtering out the pending delete transactions, right?

FitseTLT · 2025-09-01T14:29:24Z

@FitseTLT We're filtering out the pending delete transactions, right?

Yep It is not linked to this pr @trjExpensify After #65247 we are filtering out even pending delete traansactions offline. 😭

trjExpensify · 2025-09-02T11:52:41Z

@TMisiukiewicz @mountiny can you weigh in here? Was this actually intentional? It goes against the established offline pattern B for pending delete actions where we show the UI element at 50% opacity with strikethrough.

mountiny · 2025-09-02T13:06:49Z

I don't think that was intentional. I am not super close to that PR, but maybe it was a side effect of trying to improve performance. Could you create an issue for us to follow up on there?

trjExpensify · 2025-09-02T15:30:26Z

Well I kinda' worry that is what is driving this bug, if you look at the proposals on the issue. So I think we should probably pause this PR until we iron that out.

mountiny · 2025-09-02T15:56:08Z

Makes sense, I believe @TMisiukiewicz will be ooo until the end of the week though

mountiny · 2025-09-02T15:57:53Z

Asked if someone could look into this while Tomek is ooo

dukenv0307 · 2025-09-13T11:06:28Z

@mountiny @FitseTLT Any updates here?

mountiny · 2025-09-15T17:26:31Z

cc @TMisiukiewicz could you please check out the last couple of comments here?

TMisiukiewicz · 2025-09-17T08:11:32Z

Definitely it was not intentional, however I am not much familiar with this feature so it's a bit difficult for me to help you out there

trjExpensify · 2025-09-17T22:05:11Z

Okay, are these the next steps here?

Pause this PR for now.
Revert whatever in perf: create report transactions and violations derived value #65247 broke the pending delete pattern. (@TMisiukiewicz are you going to do that?)
Re-implement pending delete properly.
Re-test the "bug" this PR was created for when (3) is deployed.
Update/close this PR depending on the outcome of (4).

TMisiukiewicz · 2025-09-18T07:10:08Z

I don’t think reverting the PR makes sense, since it clearly improves performance when reading report-related transactions and violations.

I had a moment to take a closer look on the issue, and I think it's not the problem of the derived value itself. Transactions with a pending delete status are still returned there. But later in ReportScreen, we use getAllNonDeletedTransactions function:

App/src/pages/home/ReportScreen.tsx

Lines 307 to 314 in 79f111b

    
           const {transactions: allReportTransactions, violations: allReportViolations} = useTransactionsAndViolationsForReport(reportIDFromRoute); 
        
           const reportTransactions = useMemo(() => getAllNonDeletedTransactions(allReportTransactions, reportActions), [allReportTransactions, reportActions]); 
        
           // wrapping in useMemo because this is array operation and can cause performance issues 
        
           const visibleTransactions = useMemo( 
        
               () => reportTransactions?.filter((transaction) => isOffline || transaction.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE), 
        
               [reportTransactions, isOffline], 
        
           );

App/src/libs/MoneyRequestReportUtils.ts

Lines 74 to 82 in 79f111b

    
           function getAllNonDeletedTransactions(transactions: OnyxCollection<Transaction>, reportActions: ReportAction[]) { 
        
               return Object.values(transactions ?? {}).filter((transaction): transaction is Transaction => { 
        
                   if (!transaction) { 
        
                       return false; 
        
                   } 
        
                   const action = getIOUActionForTransactionID(reportActions, transaction.transactionID); 
        
                   return !isDeletedParentAction(action) && (reportActions.length === 0 || !isDeletedAction(action)); 
        
               }); 
        
           }

That function filters out deleted transactions entirely, including pending deletes.

Possible solutions I can think of:

Update getAllNonDeletedTransactions to include transactions with pending delete status.
Or, in visibleTransactions, combine results from getAllNonDeletedTransactions with pending transactions from the derived value

trjExpensify · 2025-09-19T00:45:17Z

I don’t think reverting the PR makes sense, since it clearly improves performance when reading report-related transactions and violations.

Yeah, I don't mean revert the whole PR, just unwind whatever broke the pending delete offline pattern.

Possible solutions I can think of:

Update getAllNonDeletedTransactions to include transactions with pending delete status.

Or, in visibleTransactions, combine results from getAllNonDeletedTransactions with pending transactions from the derived value

I'll let @mountiny @dukenv0307 @FitseTLT chime in on which approach sounds best.

dukenv0307 · 2025-09-23T01:53:26Z

I think we can go with the first solution

Update getAllNonDeletedTransactions to include transactions with pending delete status.

@FitseTLT

FitseTLT · 2025-09-23T21:03:45Z

I think we can go with the first solution

Update getAllNonDeletedTransactions to include transactions with pending delete status.

@FitseTLT

Yep will update it on this pr

FitseTLT · 2025-09-24T13:12:20Z

Applied the changes. Result:

2025-09-24.16-07-00.mp4

dukenv0307 · 2025-09-27T10:29:14Z

reviewing now

dukenv0307 · 2025-09-29T03:08:52Z

Reviewer Checklist

I have verified the author checklist is complete (all boxes are checked off).
I verified the correct issue is linked in the ### Fixed Issues section above
I verified testing steps are clear and they cover the changes made in this PR
- I verified the steps for local testing are in the Tests section
- I verified the steps for Staging and/or Production testing are in the QA steps section
- I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
- I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
I checked that screenshots or videos are included for tests on all platforms
I included screenshots or videos for tests on all platforms
I verified that the composer does not automatically focus or open the keyboard on mobile unless explicitly intended. This includes checking that returning the app from the background does not unexpectedly open the keyboard.
I verified tests pass on all platforms & I tested again on:
- Android: HybridApp
- Android: mWeb Chrome
- iOS: HybridApp
- iOS: mWeb Safari
- MacOS: Chrome / Safari
- MacOS: Desktop
If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
I verified there are no new alerts related to the canBeMissing param for useOnyx
I verified proper code patterns were followed (see Reviewing the code)
- I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
- I verified that comments were added to code that is not self explanatory
- I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
- I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
- I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
- I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
- I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
- I verified the JSDocs style guidelines (in STYLE.md) were followed
If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
I verified that this PR follows the guidelines as stated in the Review Guidelines
I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
I verified any variables that can be defined as constants (ie. in CONST.ts or at the top of the file that uses the constant) are defined as such
If a new component is created I verified that:
- A similar component doesn't exist in the codebase
- All props are defined accurately and each prop has a /** comment above it */
- The file is named correctly
- The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
- The only data being stored in the state is data necessary for rendering and nothing else
- For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
- Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
- All JSX used for rendering exists in the render method
- The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
If any new file was added I verified that:
- The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
If a new CSS style is added I verified that:
- A similar style doesn't already exist
- The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
- I verified that all the inputs inside a form are aligned with each other.
- I added Design label and/or tagged @Expensify/design so the design team can review the changes.
If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
For any bug fix or new feature in this PR, I verified that sufficient unit tests are included to prevent regressions in this flow.
If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: HybridApp

Screen.Recording.2025-09-29.at.10.04.35.mov

Android: mWeb Chrome

Screen.Recording.2025-09-29.at.10.00.06.mov

iOS: HybridApp

Screen.Recording.2025-09-29.at.10.06.00.mov

iOS: mWeb Safari

Screen.Recording.2025-09-29.at.09.58.36.mov

MacOS: Chrome / Safari

Screen.Recording.2025-09-29.at.09.56.21.mov

MacOS: Desktop

Screen.Recording.2025-09-29.at.10.07.17.mov

mountiny · 2025-09-29T19:30:52Z

All yours @mollfpr can you please do a final review?

OSBotify · 2025-09-30T02:35:44Z

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

OSBotify · 2025-09-30T23:32:49Z

🚀 Deployed to staging by https://github.com/mollfpr in version: 9.2.21-0 🚀

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

OSBotify · 2025-10-02T04:24:12Z

🚀 Deployed to production by https://github.com/Julesssss in version: 9.2.21-4 🚀

platform	result
🖥 desktop 🖥	failure ❌
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

OSBotify · 2025-10-02T04:47:57Z

🚀 Deployed to production by https://github.com/Julesssss in version: 9.2.21-4 🚀

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

fix bulk expense deletion iouReport total update

59ff695

FitseTLT requested a review from a team as a code owner August 13, 2025 23:21

melvin-bot bot requested review from dukenv0307 and removed request for a team August 13, 2025 23:21

dukenv0307 reviewed Aug 14, 2025

View reviewed changes

src/libs/actions/IOU.ts Show resolved Hide resolved

dukenv0307 reviewed Aug 14, 2025

View reviewed changes

FitseTLT added 2 commits August 14, 2025 16:28

Merge branch 'main' into fix-bulk-request-deletion-total-calculation-bug

c27b5bd

Merge branch 'main' into fix-bulk-request-deletion-total-calculation-bug

044559c

Christinadobrzyn mentioned this pull request Aug 19, 2025

[Due for payment 2025-10-09] [$250] Android - Report - Amount is not updated smoothly after deleting expenses from report. #67641

Closed

8 tasks

FitseTLT added 2 commits August 26, 2025 16:20

Merge branch 'main' into fix-bulk-request-deletion-total-calculation-bug

44a688e

grey out total on pending deletion transaction

ef451f5

FitseTLT requested a review from dukenv0307 August 26, 2025 15:14

FitseTLT added 2 commits August 26, 2025 18:23

fix test

5021b02

fix import

77bf990

dukenv0307 reviewed Aug 26, 2025

View reviewed changes

Merge branch 'main' into fix-bulk-request-deletion-total-calculation-bug

589b6d7

Merge branch 'main' into fix-bulk-request-deletion-total-calculation-bug

da832dc

Merge branch 'main' into fix-bulk-request-deletion-total-calculation-bug

a5bd21f

FitseTLT requested a review from a team as a code owner September 1, 2025 14:26

Merge branch 'main' into fix-bulk-request-deletion-total-calculation-bug

68ae09e

FitseTLT added 2 commits September 24, 2025 15:56

Merge branch 'main' into fix-bulk-request-deletion-total-calculation-bug

1bda97d

include pending action delete transactions

7286dab

dukenv0307 approved these changes Sep 29, 2025

View reviewed changes

melvin-bot bot requested a review from mollfpr September 29, 2025 03:09

mollfpr approved these changes Sep 30, 2025

View reviewed changes

mollfpr merged commit ff8a107 into Expensify:main Sep 30, 2025
21 checks passed

OSBotify mentioned this pull request Sep 30, 2025

Deploy Checklist: New Expensify 2025-09-30 #71621

Closed

72 tasks

	const hasPendingAction = useMemo(() => {
	return transactions.some(getTransactionPendingAction);
	}, [transactions]);

Conversation

FitseTLT commented Aug 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Details

Fixed Issues

Tests

Offline tests

QA Steps

PR Author Checklist

Screenshots/Videos

Uh oh!

melvin-bot bot commented Aug 13, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

trjExpensify commented Aug 19, 2025

Uh oh!

dukenv0307 commented Aug 22, 2025

Uh oh!

dukenv0307 commented Aug 26, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dukenv0307 commented Aug 28, 2025

Uh oh!

FitseTLT commented Aug 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dukenv0307 commented Aug 28, 2025

Uh oh!

FitseTLT commented Aug 28, 2025

Uh oh!

dukenv0307 commented Aug 29, 2025

Uh oh!

trjExpensify commented Aug 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dukenv0307 commented Sep 1, 2025

Uh oh!

FitseTLT commented Sep 1, 2025

Uh oh!

trjExpensify commented Sep 2, 2025

Uh oh!

mountiny commented Sep 2, 2025

Uh oh!

trjExpensify commented Sep 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mountiny commented Sep 2, 2025

Uh oh!

mountiny commented Sep 2, 2025

Uh oh!

dukenv0307 commented Sep 13, 2025

Uh oh!

mountiny commented Sep 15, 2025

Uh oh!

TMisiukiewicz commented Sep 17, 2025

Uh oh!

trjExpensify commented Sep 17, 2025

Uh oh!

TMisiukiewicz commented Sep 18, 2025

Uh oh!

trjExpensify commented Sep 19, 2025

FitseTLT commented Aug 13, 2025 •

edited

Loading

FitseTLT commented Aug 28, 2025 •

edited

Loading

trjExpensify commented Aug 30, 2025 •

edited

Loading

trjExpensify commented Sep 2, 2025 •

edited

Loading