(1/2) Implement store/caching for attachments #65321

NJ-2020 · 2025-07-02T09:30:30Z

Explanation of Change

Original PR: #63723

This PR adds functionality to store and cache attachment files and markdown attacfhment (including images & videos) across all platforms, enabling offline preview.

Note: image preview in offline mode will be implemented in PR (2/2).

We use CacheAPI for web and filesystem for native platforms to manage attachment storage.

Each attachment has a unique ID (attachment_id / data-attachment-id) for storing and previewing files on both web and native

For new attachments, we use the data-attachment-id parameter, for older attachments which doesn't have this parameter, we combine the reportActionID with the attachment's index in the selection list:

Single attachment: reportActionID_0
Multiple attachments (inside on action/message/comment) reportActionID_0, reportActionID_1, etc

Fixed Issues

$ #9402
PROPOSAL: #9402 (comment)

Tests

Observing changes

Web:

Open inspect element
Go to > Applications tab
OnyxDB:
Go to > Storage > IndexedDB > OnyxDB > keyvaluepairs
Click 🔄 to reload the lists
Click the input search bar, and search for attachment key i.e attachment_...
Cache API
Go to Storage > Cache storage > attachments
See attachment lists

Screen.Recording.2025-08-21.at.13.24.41.mov

Native:

Physical device
- Android:
1. Go to your Media/Files
2. Search for com.expensify.chat.dev or similar, usally it's located under root/android/data/com.expensify.chat.dev
3. Look for files folder or related folder i.e Documents/DCIM, for better results you can try to filter out only images
- IOS:
Note: I don't have IOS physical device, so it might be similar to emulator device
1. Go to Files
2. Search for New Expensify Dev or similar
3. Open that app/folder, lookup for new attachment file
Emulator device
- Android:
1. Open 2 terminal, A & B:
2. A(Terminal): Run this command to see the list of attachment files:
```
adb root

adb shell

cd /data/user/0/com.expensify.chat.dev/files/

ls // return list of files (including attachment) 
```
1. B(Terminal): Run this command to preview the attachment file
```
adb root // if necessary

adb exec-out run-as com.expensify.chat.dev cat files/attachment_file_name_here  > ~/Desktop/output_file_name_here
```
3: B(Terminal): Go to Desktop > Open newly created file to preview the attachment
- IOS:
1. Go to Files
2. Search/Open New Expensify Dev
3. Lookup for new attachments

For more details can been seen in the attached recording videos below

Test cases:

Upload attachment file

Open Expensify App
Go to any chat
Upload a single or multiple attachment files
Observe the changes:
Make sure list of new attachment is created in Onyx, here's the expectedResult:

Web:

{
    attachmentID: "...",
    remoteSource: "", // << empty here since it's coming from local source
}

Native:

{
    attachmentID: "...",
    source: "file://..." // << local device uri
    remoteSource: "", // << empty here since it's coming from local source
}

And same also for CacheAPI (web/desktop-only:

Markdown image attachment

Open Expensify App
Go to any chat
Click the composer and type any single or multiple markdown image url i.e ![](https://images.unsplash.com/photo-1726066012751-2adfb5485977?w=100)
Observe the changes:
Make sure list of new attachment is created in Onyx, here's the expectedResult:

Web:

{
    attachmentID: "..._1", // << make sure the attachment id pattern for markdown attachment is: ..._1
    remoteSource: "https://images.unsplash.com/photo-1726066012751-2adfb5485977?w=100", // << markdown image url

Native:

{
    attachmentID: "..._1", // << make sure the attachment id pattern for markdown attachment is: ..._1
    source: "file://..." // << local device uri
    remoteSource: "https://images.unsplash.com/photo-1726066012751-2adfb5485977?w=100", // << markdown image url
}

And same also for CacheAPI (web/desktop-only:

Markdown video attachment

Open Expensify App
Go to any chat
Click the composer and type any single or multiple markdown image url i.e ![](https://cdn.pixabay.com/video/2021/02/18/65562-515098354_large.mp4)
Observe the changes:
Make sure list of new attachment is created in Onyx, here's the expectedResult:

Web:

{
    attachmentID: "..._1", // << make sure the attachment id pattern for markdown attachment is: ..._1
    remoteSource: "https://cdn.pixabay.com/video/2021/02/18/65562-515098354_large.mp4", // << markdown image url

Native:

{
    attachmentID: "..._1", // << make sure the attachment id pattern for markdown attachment is: ..._1
    source: "file://..." // << local device uri
    remoteSource: "https://cdn.pixabay.com/video/2021/02/18/65562-515098354_large.mp4", // << markdown image url
}

And same also for CacheAPI (web/desktop-only: // TODO, add here for video markdown

Old attachment offline behaviour (only available in dev mode / next PR (2/2) )

Codebase changes:

Go to ImageRenderer.tsx
Add this code - (note: please remove this code to prevent duplicate logging console when testing):

function ImageRenderer({tnode}: ImageRendererProps) {
    ...
    const attachmentID = htmlAttribs[CONST.ATTACHMENT_ID_ATTRIBUTE];
    const [attachment, attachmentResult] = useOnyx(`${ONYXKEYS.COLLECTION.ATTACHMENT}${attachmentID}`, {canBeMissing: true});
    ...

    useEffect(() => {
        // Prevent attachment from being re-cache
        if (attachmentResult.status !== 'loaded') {
            return;
        }

        const attachmentSource = isAttachmentOrReceipt ? attachmentSourceAttribute : htmlAttribs.src;
        getCachedAttachment({attachmentID, attachment, currentSource: attachmentSource});
    }, [attachmentID, attachment, source, attachmentResult]);

    ...
}

Open Expensify app
Open any chat that has attachment uploaded before this PR
Observe the changes both for attachment file and markdown attachment:
Make sure list of new attachment is created in Onyx, here's the expectedResult:

Web:

AttachmentFile

{
    attachmentID: "..._1", // << make sure the attachment id pattern for old attachment is (or same as markdown attachment): ..._1
    remoteSource: "", // << empty since it's coming from local source

MarkdownAttachment

{
    attachmentID: "..._1", // << make sure the attachment id pattern for old attachment is (or same as markdown attachment): ..._1
    remoteSource: "https://images.unsplash.com/photo-1726066012751-2adfb5485977?w=100", // << markdown image url

Native:

AttachmentFile

{
    attachmentID: "..._1", // << make sure the attachment id pattern for old attachment is (or same as markdown attachment): ..._1
    source: "file://..." // << local device uri
    remoteSource: "", // << empty since it's coming from local source

MarkdownAttachment

{
    attachmentID: "..._1", // << make sure the attachment id pattern for old attachment is (or same as markdown attachment): ..._1
    source: "file://..." // << local device uri
    remoteSource: "https://images.unsplash.com/photo-1726066012751-2adfb5485977?w=100", // << markdown image url

Update markdown attachment (only available in dev mode / next PR (2/2) )

Codebase changes:

Go to ImageRenderer.tsx
Add this code - (note: please remove this code to prevent duplicate logging console when testing):

function ImageRenderer({tnode}: ImageRendererProps) {
    ...
    const attachmentID = htmlAttribs[CONST.ATTACHMENT_ID_ATTRIBUTE];
    const [attachment] = useOnyx(`${ONYXKEYS.COLLECTION.ATTACHMENT}${attachmentID}`, {canBeMissing: true});   

    ...

    useEffect(() => {
        if (attachmentResult.status !== 'loaded') {
            return;
        }
        getCachedAttachment({attachmentID, attachment, currentSource: source});
    }, [attachmentID, attachment, source, attachmentResult]);

    ...
}

Open Expensify app
Go to any chat
Select any markdown attachment action > Edit comment
Change with new markdown attachment link
Observe the changes:
Make sure attachment stored in Onyx is updated, here's the expectedResult:

Web:

{
    attachmentID: "..._1", //
    remoteSource: "https://images.pexels.com/photos/577585/pexels-photo-577585.jpeg", // << new updated markdown image url

Native:

{
    attachmentID: "..._1",
    source: "file://..." // << new updated local device uri
    remoteSource: "https://images.pexels.com/photos/577585/pexels-photo-577585.jpeg", // << new updated markdown image url
}

And same also for CacheAPI (web/desktop-only:

Delete markdown/attachment

Open Expensify App
Go to any chat
Delete any markdown attachment or any attachment file
Observe the changes - make sure the selected attachment is deleted both in Onyx and CacheAPI

Verify that no errors appear in the JS console

Offline tests

Same as tests, for markdown attachment it will requires internet connection

QA Steps

Verify that no errors appear in the JS console

Same as tests

PR Author Checklist

Screenshots/Videos

Android: Native

Upload attachment file

9402_android_native_attachment_file.mp4

Markdown attachment

9402_android_native_markdown_attachment.mp4

Update attachment

9402_android_native_update_attachment.mp4

Delete attachment

9402_android_native_delete_attachment.mp4

Old attachment behaviour

9402_android_native_old_attachment_behaviour.mp4

Android: mWeb Chrome

Upload attachment file

9402_android_mweb_attachment_file.mp4

Markdown image attachment

9402_android_mweb_markdown_image.mov

Markdown video attachment

9402_android_mweb_markdown_video.mp4

Update attachment

9402_android_mweb_update_attachment.mp4

Delete attachment

9402_android_mweb_delete_attachment.mov

Old attachment behaviour

9402_android_mweb_old_attachment_behaviour.mp4

iOS: Native

Upload attachment file

9402_ios_native_attachment_file.mp4

Markdown attachment

9402_ios_native_markdown_attachment.mov

Update attachment

9402_ios_native_update_attachment.mp4

Delete attachment

9402_ios_native_delete_attachment.mov

Old attachment behaviour

9402_ios_native_old_attachment_behaviour.mp4

iOS: mWeb Safari

Upload attachment file

9402_ios_mweb_attachment_file.mov

Markdown image attachment

9402_ios_mweb_markdown_image.mov

Markdown video attachment

9402_ios_mweb_markdown_video.mov

Update attachment

9402_ios_mweb_update_attachment.mov

Delete attachment

9402_ios_mweb_delete_attachment.mov

Old attachment behaviour

9402_ios_mweb_old_attachment_behaviour.mov

MacOS: Chrome / Safari

Upload attachment file

9402_web_attachment_file.mov

Markdown image attachment

9402_web_markdown_image.mov

Markdown video attachment

9402_web_markdown_video.mov

Update attachment

9402_web_update_attachment.mp4

Delete attachment

9402_web_delete_attachment.mp4

Old attachment behaviour

9402_web_old_attachment_behaviour.mp4

MacOS: Desktop

Upload attachment file

9402_desktop_attachment_file.mov

Markdown image attachment

9402_desktop_markdown_image.mov

Markdown video attachment

9402_desktop_markdown_video.mov

Update attachment

9402_desktop_update_attachment.mov

Delete attachment

9402_desktop_delete_attachment.mov

Old attachment behaviour

9402_desktop_old_attachment_behaviour.mov

…rors, and fixing some issues

NJ-2020 · 2025-10-11T03:47:32Z

@parasharrajat Thanks for reviewing! Can you please kindly speed up / prioritize this one and start testing?, I want to finish this PR asap. Many thanks

parasharrajat · 2025-10-11T16:09:42Z

Ok, Thanks. I am going to use some internal insight before moving here. Need to confirm a few things.

NJ-2020 · 2025-10-14T03:53:52Z

@parasharrajat Please kindly keep me posted on this one. Thanks!

parasharrajat · 2025-10-15T07:21:06Z

No update for today. Going to check back in the evening.

NJ-2020 · 2025-10-19T02:02:36Z

No update for today. Going to check back in the evening.

@parasharrajat Any updates?, it's already been a week

parasharrajat · 2025-10-21T00:32:25Z

I want to determine what should be done with this PR. Do we need these #65321 (comment) changes, or is the expected behavior changed?

As the issue was created long ago, attachment behavior has changed since we started working on this implementation. I want to be sure about the expected behaviour before we merge this PR.

This PR will improve the attachment caching, so the issue should say so for clarity.

If needed, I will bring in some other C+ to help speed things up.

parasharrajat · 2025-10-21T00:33:22Z

As per the linked issue, the app is already working as expected.

parasharrajat · 2025-10-21T00:42:34Z

Slack discussion https://expensify.slack.com/archives/C02NK2DQWUX/p1761007224828439

NJ-2020 · 2025-10-21T09:43:50Z

#65321 (comment)
#65321 (comment)

As far as I remember, the original issue is not about cache image but rather than improving uploading large attachment i.e loader, opacity, etc

But but as time goes by, pull requests, discussions, there's some bugs/issues, and @kidroca and we ended up ending by adding local attachment offline support using data-attachment-id

And currently, there's some bugs in the attachment flow and we ended up holding to this PR:

[HOLD for #9402][$500] Conversation - The photo is not shown in the conversation history while the user is offline #64055 (comment)
Conversation - Attachment fails to load after internet reconnection and page refresh #69752
Attachment preview server/offline

I'll try to re-visit again the original issue and check it.

https://expensify.slack.com/archives/C02NK2DQWUX/p1761007224828439

I can't access this conversation link

@parasharrajat I think maybe we should start discussion/ask to the internal team/BZ member of the current to make sure everything is correct/aligned, and it would be better if you'd it inside the expensify-open-source channel, so I can see/discuss it too. Many thanks

parasharrajat · 2025-10-21T10:14:23Z

Thanks for the info. Yes, I agree we should start a group discussion. Normally, we start with a P/S statement for such large issues and then work on a design doc to lay down implementation details and design before moving on to implementation. We jumped the ladder on this issue as it is very old, and we picked things from previous contributors.

At this point, I do not have clarity on the impact of this PR/implementation on the app. I would suggest we take a step back and spend some time on the missed steps, and take input from the internal team. If these changes are not useful to the app anymore, we should not invest more time in this and compensate for the efforts so far.

Let's start with a Problem-solution statement(See contributing docs for instructions) first and post it on the Slack open source channel. You should already have everything to write it. Then I will tag the necessary engineers to evaluate it. Let me know if you need any help with it.

NJ-2020 · 2025-10-21T10:20:41Z

Sure, I'll do it soon. Thanks

NJ-2020 · 2025-10-23T07:32:06Z

Let's start with a Problem-solution statement(See contributing docs for instructions) first and post it on the Slack open source channel. You should already have everything to write it. Then I will tag the necessary engineers to evaluate it. Let me know if you need any help with it.

Sorry for the delay, @parasharrajat. I'm not sure if this is the best approach to evaluate the current/expected behavior, since we've been working on this PR for around 6 months including with many changes.

I think it might be better to tag the BZ team directly in this PR/linked issue or in a new Slack discussion to evaluate & make sure the current/expected behaviour. What do you think?

Thanks

parasharrajat · 2025-10-23T10:59:35Z

Yes, we have taken a lot of time on the first implementation. When we started with this after discussion on the issue, I expected this PR to be ready on the first go, other than code changes. But we discovered many cases, and it took a few months to be ready. Yes, my feedback was crucial, but it should have been ready sooner. Due to it took a lot of time in implementation edge case discovery, there have been delays from my reviews, as it is not possible for me to dedicate 1 or 2 months to this Pr only for implementation.

I'm not sure if this is the best approach to evaluate the current/expected behavior, since we've been working on this PR for around 6 months, including many changes.

This is the default process here for implementation/new features tasks. I was suggesting this to help us move forward with this implementation.

We can ask BZ to reevaluate the expected behaviour, but as I explained earlier, it is not very clear now, which means we might have to drop this here, as I don't see any differences.

parasharrajat · 2025-10-23T11:02:36Z

Can you help me with a summary of the problem/solution here? I am going to tag BZ on the issue. I could write that down, but since I don't have a clear vision of these changes, I will overlook their importance. There will be more PRs ahead as implementation is not yet completed.

Problem: Issue in the app that you are trying to solve.
Solution: Your approach to it.

Please be detailed.

NJ-2020 · 2025-10-27T03:00:22Z

@parasharrajat Ah, I found specifically where when we decided to move to local (store/caching) attachment:

As we've discussed, the primary enhancement I propose is utilizing local content when available. To map remote sources to local content effectively, we need to introduce an attachmentID generated by the client and included in requests. This identifier has been a topic in our recent Slack discussions, particularly in our latest thread which can be found here

Here's the slack discussion thread: https://expensify.slack.com/archives/C01GTK53T8Q/p1707270017261459

FYI: What I've already seen, it seems there's a lot discussion about improving uploading attachment experience

NJ-2020 · 2025-10-27T03:15:56Z

Here's summarize problem/bugs we're trying to solve:

Problems

Image + Text Sent as Separate Messages

For creation, we do make a single api call with both the attachment, and the message. But when we retrieve the report we get back 2 messages, one for the text, one for the attachment.

No Inline Image Markdown Support

We haven't added any markdown syntax for creating it [inline images]... Which means that if you edit it, it breaks

AuthToken Expiration Issues

Also linking to an image uploaded to the thread failed, because the authToken expired

Duplicate images break carousel

Our current approach relies on the uniqueness of attachment source URLs for functionalities like opening the attachment carousel at a specific image. However, public images can be embedded multiple times across comments, leading to non-unique URLs

Images Without Extensions Don't Render (I've already mentioned about this bug previously ^^)

Public images, such as those from Unsplash, often lack extensions, causing our fallback content to render instead

Markdown in Alt Attributes Becomes HTML

markdown syntax like ![*bold*](https://example/img.jpg) is translated into HTML as <img src="https://example/img.jpg" alt="<strong>bold</strong>" />, note the alt attribute.

No Short Syntax for Images

can we also support the syntax that doesn't require an 'alt text': !(https://...)

Large File Upload Limitations (This is where when local attachment comes in)

Currently, our attachment size limit is set to 24MB... Our current upload process is designed to transmit attachments in a single attempt without supporting pause-and-resume functionality

Here's the proposal

So, local attachment is introduced where we want to add large attachment support, the current limit is 24MB and uploading large attachment like 200MB or 300MB will took few times to reach the BE/server and thus we will display the attachment immidietly to the user using local path:

Your conclusions are correct - When possible we'll load user's own attachments from their original local path, and when not possible from server.

For mobile “local path” might be the original attachment or a copy in a temp folder. It depends on the library (we use at least 2 image picker and a document picker).

For web and desktop, since we don’t have FS acess, we'll put a copy in IndexedDB and use that.
In the future it might be possibly to request permission to access to the original file in future sessions

And here's another step-by-step about large file upload support (BE+FE): https://expensify.slack.com/archives/C01GTK53T8Q/p1721930274037499?thread_ts=1707270017.261459&cid=C01GTK53T8Q

Backend Strips HTML Attributes

The backend is actually stripping everything and adding a set of defaults... Backend strips all attributes (maybe even the whole node)

Note: Some of them has already been fixed.

NJ-2020 · 2025-10-27T03:16:33Z

@parasharrajat Please let me know wdyt ^^. Thanks

parasharrajat · 2025-10-27T10:59:38Z

Ah, it is wrong. I am not asking to list down all the issues you found in this flow.

I am asking the only problem we are solving here with this implementation for the linked issue. The problem you have in mind which working on with this implementation or you had while writing proposal.

HEre is a sample

Proposal: Fix IndexedDB transaction memory leak in multiMerge
Background: Onyx uses IndexedDB (via idb-keyval) as the storage layer on web. The multiMerge operation is one of the most frequently called storage operations, executing thousands of times during app initialization for accounts with substantial data. Currently, multiMerge uses a manual transaction pattern where it directly accesses the IDBObjectStore via idbKeyValStore('readwrite', (store) => {...}) to perform read-then-write operations within a single transaction. This pattern creates a transaction object that remains in memory along with all its associated IDBRequest objects and promise chains. For heavy accounts in Expensify, a single page load can trigger thousands of multiMerge calls, each creating these transaction structures.
Problem: When users with heavy accounts load the app, if Onyx performs thousands of multiMerge operations, then the manual transaction pattern retains 383MB+ of memory in IDBDatabase and IDBTransaction objects that are never garbage collected, causing the app to crash or become unresponsive.
Solution: Fix the multiMerge implementation to eliminate manual transaction management and let idb-keyval handle transaction lifecycle automatically ends. The specific code change is moving the .then(() => undefined) outside the idbKeyValStore callback so the transaction can complete immediately after all put operations finish, rather than being kept alive by the outer promise chain.
Impact: Memory snapshots show this reduces the retained size from 383,727KB (36% of total heap) down to ~1,000KB (negligible). This also prevents the accumulation of 100,000+ IDBTransaction objects in memor

NJ-2020 · 2025-10-30T02:29:19Z

@parasharrajat Sorry for the delay,

Ah, it is wrong. I am not asking to list down all the issues you found in this flow.

FYI: For the above comments, I am just answering this question why we need to create/have this PR for local store attachment not actual proposal/problem statement

I want to determine what should be done with this PR. Do we need these #65321 (comment) changes, or is the expected behavior changed?

I am asking the only problem we are solving here with this implementation for the linked issue. The problem you have in mind which working on with this implementation or you had while writing proposal.

But here's the proposal for this PR/local attachment caching

Proposal: Add/support large file for uploading attachment

Background:

Currently, the app only support max 24mb size of file when uploading attachment and doesn't not handle byte-by-byte/chunk uploading, cancelled/resume request and when refreshing the app, it took sometimes to fully loaded the attachment from the server/BE

Problem:

User cannot upload larger/various attachment size i.e 31, 50MB size of attachment
When the attachment is still uploading to the server, user can leave the page without any dialog/confirmation to exit/cancel
When attachment is uploaded to the server, it took sometimes to fully loaded the attachment from the server which seems a bit laggy (as sender)
The attachment api doesn't support ranges (more details can bee seen here)

Solution:

Allow large attachment file upload i.e 1GB
When user tries to leave the page, add confirmation dialog / progress indicator of the attachment
Support chunk/range uploading (streaming/parallel) enabling pause and resume functionality
When displaying attachment, prefer local path for faster performance especially when dealing with large attachments
Allow background uploading, specifically on native, when user close the app, allow the attachment to be still uploaded on the background

Impact:

This will allow user to upload various/large attachment file size, without worrying (performance, laggy, cancelled request, lost connection, closed app, etc)

parasharrajat · 2025-10-30T10:33:13Z

OK, Thanks for sharing this. I will share this internally and have someone pulled in here to help.

NJ-2020 · 2025-11-05T03:23:22Z

@parasharrajat Any updates?

parasharrajat · 2025-11-06T14:20:21Z

Not yet. We will have on it next week. I will try to settle this discussion next week on this PR.

parasharrajat · 2025-11-10T12:30:28Z

Looking into this today.

parasharrajat · 2025-11-17T07:32:32Z

Internal discussion link https://expensify.slack.com/archives/C02NK2DQWUX/p1763364722326279

JmillsExpensify

No product review required. Unsubscribing.

NJ-2020 and others added 30 commits June 6, 2025 14:35

feat: implement store/caching attachment for native

2fe2027

Merge branch 'Expensify:main' into new-feat/9402-1

5907988

Merge branch 'Expensify:main' into new-feat/9402-1

5381d33

implement store/caching for web and fix some issues

fc2382a

remove unnecessary code

79f2ad2

fix eslint errors

11b7669

fix: eslint errors & store file path for native

78aaa7b

fix: remove attachment when deleting comment, improvements, eslint er…

6ba6580

…rors, and fixing some issues

remove unnecessary changes

b690613

fix: eslint errors

ad8e005

fix: eslint errors

041bcbc

fix: attachmentID is returning undefined

393ad06

fix: remove unnecessary code

6b23b6f

Merge branch 'Expensify:main' into new-feat/9402-1

21f59ee

add missing comments

60ed019

revert showImagePicker changes

1e56909

Merge branch 'Expensify:main' into new-feat/9402-1

efeee2b

Merge branch 'Expensify:main' into new-feat/9402-1

1efadb4

feat: add unit test file

e395df4

fix some comments and improve the code

63ad3f7

Merge remote-tracking branch 'origin' into new-feat/9402-1

70ff800

fix some comments & issues

648c196

remove unnecessary checks

bf021da

Merge branch 'Expensify:main' into new-feat/9402-1

9dc2822

refactor buildOptimisticAddCommentReportAction to use parameter object

7f79697

fix: getHtmlWithAttachmentID, some issues & errors

8b118a1

fix: eslint error

6324aa1

Merge branch 'main' into new-feat/9402-1

ce31649

Merge branch 'main' into new-feat/9402-1

22ddea1

Merge branch 'Expensify:main' into new-feat/9402-1

0b9bde7

Merge branch 'main' into new-feat/9402-1

2ffa15a

fix failing tests

a64bbe0

Merge branch 'main' into new-feat/9402-1

068c814

Merge branch 'main' into new-feat/9402-1

10bbc64

Merge branch 'main' into new-feat/9402-1

cb1d83e

JmillsExpensify reviewed Dec 4, 2025

View reviewed changes

(1/2) Implement store/caching for attachments #65321

Are you sure you want to change the base?

(1/2) Implement store/caching for attachments #65321

Uh oh!

Conversation

NJ-2020 commented Jul 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Explanation of Change

Fixed Issues

Tests

Observing changes

Test cases:

Offline tests

QA Steps

PR Author Checklist

Screenshots/Videos

Uh oh!

NJ-2020 commented Oct 11, 2025

Uh oh!

parasharrajat commented Oct 11, 2025

Uh oh!

NJ-2020 commented Oct 14, 2025

Uh oh!

parasharrajat commented Oct 15, 2025

Uh oh!

NJ-2020 commented Oct 19, 2025

Uh oh!

parasharrajat commented Oct 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

parasharrajat commented Oct 21, 2025

Uh oh!

parasharrajat commented Oct 21, 2025

Uh oh!

NJ-2020 commented Oct 21, 2025

Uh oh!

parasharrajat commented Oct 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

NJ-2020 commented Oct 21, 2025

Uh oh!

NJ-2020 commented Oct 23, 2025

Uh oh!

parasharrajat commented Oct 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

parasharrajat commented Oct 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

NJ-2020 commented Oct 27, 2025

Uh oh!

NJ-2020 commented Oct 27, 2025

Problems

Uh oh!

NJ-2020 commented Oct 27, 2025

Uh oh!

parasharrajat commented Oct 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

NJ-2020 commented Oct 30, 2025

Proposal: Add/support large file for uploading attachment

Background:

Problem:

Solution:

Impact:

Uh oh!

parasharrajat commented Oct 30, 2025

Uh oh!

NJ-2020 commented Nov 5, 2025

Uh oh!

parasharrajat commented Nov 6, 2025

Uh oh!

parasharrajat commented Nov 10, 2025

Uh oh!

parasharrajat commented Nov 17, 2025

Uh oh!

JmillsExpensify left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

NJ-2020 commented Jul 2, 2025 •

edited

Loading

parasharrajat commented Oct 21, 2025 •

edited

Loading

parasharrajat commented Oct 21, 2025 •

edited

Loading

parasharrajat commented Oct 23, 2025 •

edited

Loading

parasharrajat commented Oct 23, 2025 •

edited

Loading

parasharrajat commented Oct 27, 2025 •

edited

Loading