(1/2) Implement store/caching for attachments by NJ-2020 · Pull Request #63723 · Expensify/App

NJ-2020 · 2025-06-07T12:26:23Z

Explanation of Change

Store/Cache attachment when uploading a file or markdown text link attachment i.e ![](https://images.unsplash.com/...)

Fixed Issues

$ #9402
PROPOSAL: #9402 (comment)

Tests

Same as QA

Verify that no errors appear in the JS console

Offline tests

Same as QA

QA Steps

Verify that no errors appear in the JS console

Prerequisites: DEV mode only

Open Expensify App
Go to any chat
Open inspect element and go to > Applications tab

File Upload
1. Open attachment picker
2. Select any file
3. Go to CacheAPI/Onyx storage for web and observe the changes

Markdown text link attachment
1. Go to input chat
2. Type any markdown text link attachment e.g ![](https://images.unsplash.com/...) and send it
3. Go to CacheAPI (web-desktop only) or Onyx (attachment_{id}) storage and observe the changes

PR Author Checklist

Screenshots/Videos

Android: Native

9402_android_native.mov

Android: mWeb Chrome

9402_android_mweb.mov

iOS: Native

9402_ios_native.mov

iOS: mWeb Safari

I have an issue while inspecting the web)

MacOS: Chrome / Safari

9402_web.mov

MacOS: Desktop

9402_desktop.1.mov

…rors, and fixing some issues

melvin-bot · 2025-06-08T14:40:23Z

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

parasharrajat · 2025-06-08T14:58:26Z

src/components/AttachmentPicker/index.native.tsx

        (imagePickerFunc: (options: CameraOptions, callback: Callback) => Promise<ImagePickerResponse>): Promise<Asset[] | void> =>
            new Promise((resolve, reject) => {
-                imagePickerFunc(getImagePickerOptions(type, fileLimit), (response: ImagePickerResponse) => {
+                imagePickerFunc(getImagePickerOptions(type, fileLimit), async (response: ImagePickerResponse) => {


We don't allow async await.

I am still waiting for this comment: #63723 (comment)

Reverting this changes due to this comment

Will fix it in the next PR

parasharrajat · 2025-06-08T15:00:04Z

src/components/AttachmentPicker/index.native.tsx

+                    if (!response.assets?.length) {
+                        return resolve();
+                    }

+                    const localCopies = await keepLocalCopy({
+                        files: response.assets.map((asset) => ({
+                            uri: asset.uri,
+                            fileName: asset.fileName ?? '',
+                        })) as [FileToCopy, ...FileToCopy[]],
+                        destination: 'documentDirectory',
+                    });
+
+                    const assets = localCopies.map((localCopy, index) => {
+                        if (localCopy.status !== 'success') {
+                            throw new Error('Failed to create local copy for file');
+                        }
+
+                        return {
+                            ...(response.assets?.at(index) ?? {}),
+                            uri: localCopy.localUri,
+                        };
+                    });
+
+                    const targetAsset = assets.at(0);
+                    const targetAssetUri = targetAsset?.uri;


We not need to cache the attachment while the user is adding one. Let's only worry about the message attachments for now.

We're not caching it, this for uploading attachment from Attachment picker specifically from Choose from Gallery where the files are copied to cache directories but we need to copy it into document directories

More info: #63723 (comment)

Replied on that linked thread. I think this is kind of out of scope of this issue.

parasharrajat · 2025-06-08T15:01:55Z

src/components/HTMLEngineProvider/HTMLRenderers/ImageRenderer.tsx

+    const imageSource = processedPreviewSource;
+    // const isAuthTokenRequired = isLocalFile(imageSource) ? false : isAttachmentOrReceipt;
+    const isAuthTokenRequired = isAttachmentOrReceipt;


Didn't understand this change?

Ohh sorry, this is because when rendering attachment specifically using local uri, its failing to load the attachment, it's because we are passing the isAuthTokenRequired true for local uri

const isAuthTokenRequired = isLocalFile(imageSource) ? false

But this says false for local file.

Yes, right we need to pass false for local uri

But the previous logic was doing the same so why did you change it?

Nope

App/src/components/HTMLEngineProvider/HTMLRenderers/ImageRenderer.tsx

Lines 85 to 89 in f09f3a1

const thumbnailImageComponent = (

<ThumbnailImage

previewSourceURL={processedPreviewSource}

style={styles.webViewStyles.tagStyles.img}

isAuthTokenRequired={isAttachmentOrReceipt}

I think we can revert this changes because this related for retrieving attachment i.e the second phase of the PR (2/2), wdyt?

parasharrajat · 2025-06-08T15:07:43Z

src/libs/actions/Attachment/index.native.ts

+        return;
+    }
+    if (uri.startsWith('file://')) {
+        Onyx.set(`${ONYXKEYS.COLLECTION.ATTACHMENT}${attachmentID}`, {


Let's convert this collection to store attacments into a a collection for report, not per attachment basis.

So `${ONYXKEYS.COLLECTION.ATTACHMENT}${reportId}. This way we can subscribe this key in the report screen and get the source for any attachment otherwise, we will have to subscribe to each attachment separately.

Please let me know how it looks first. Does this increase complexity and impact performance?

Overall, I believe we should create a custom hook to handle attachments. I am particularly curious on how you will handle the remote source change from backend. Can you show me code on how you will handle it?

Let's convert this collection to store attacments into a a collection for report, not per attachment basis.

I think we're using the data-attachment-id attribute value from the attachment tag for both storing/retrieving attachment

Basically if there's any attachment it will render through ImageRenderer|VideoRenderer|AnchorRenderer, inside that we can retrieve the data-attachment-id attribute value provided from BE and use the attachment id value to get the local source from Onyx

Maybe for alternative option instead of passing reportID we can use the reportActionID which is more easier to handle delete attachment, retrieving and others

But I think we can use the data-attachment-id from BE, which is specifically for attachments. For old attachments without attachment IDs, we can use reportActionID + {index}.

Please let me know how it looks first. Does this increase complexity and impact performance?

I am not sure if it's really impacting our app perfomance, because for every attachment we need to get the list of attachments of the current report(which can be more than 1), but we only need 1 attachment source from all the lists and we need to filter out again that matches with the data-attachment-id value

Wdyt?

Overall, I believe we should create a custom hook to handle attachments. I am particularly curious on how you will handle the remote source change from backend. Can you show me code on how you will handle it?

Currently, I handle it inside the getAttachmentSource function, where first I compared the current source from BE with attachment.remoteSource, if there's any differences, then we will recache the attachment and show the new one

App/src/libs/actions/Attachment/index.native.ts

Lines 47 to 56 in 21f59ee

function getAttachmentSource(attachmentID: string, currentSource: string) {

if (!attachmentID) {

return;

}

const attachment = attachments?.[`${ONYXKEYS.COLLECTION.ATTACHMENT}${attachmentID}`];

if (attachment?.remoteSource && attachment.remoteSource !== currentSource) {

storeAttachment(attachmentID, currentSource);

return currentSource;

}

Edit:
Ah, you're right I think we need to make new hook for retrieving attachment specifically for CacheAPI i.e like useOnyx, because it's returning Promise value

But I think I'll do it in the second phase of the PR, right?

yeah, second PR sounds good,

parasharrajat · 2025-06-08T15:09:18Z

src/libs/actions/Attachment/index.native.ts

+        return;
+    }
+
+    RNFetchBlob.config({fileCache: true, path: `${RNFetchBlob.fs.dirs.DocumentDir}/${attachmentID}`})


Not a good idea to store in DocumentDir as it can not be cleared but system cleanup. We should instead create a subfolder in the CacheDir and save attachments there.

When we are clearly the cacheDir on signout. We exclude this folder from that cleanup.

It's because when a user upload an attachment, if we save the file into cache dir, the attachment preview will gone if the user restart the app/device

So to fix this we need to store the attachment into documents directory i.e com.expensify.com/files/attachment_{id}

We will recache the attachment if there's new changes from BE, if not then we will use from the pre-cached attachment

I don't think we need to worry about the attachment preview when the user is uploading the attachment. Until it is sent, we don't have to save it for offline preview. If needed we would do that later in different PR.

I don't think we need to worry about the attachment preview when the user is uploading the attachment. Until it is sent

Agree, so I think we can do it inside the storeAttachment function

we don't have to save it for offline preview

I think it will show weird behavior to the user if the user close and then reopen the app, because it will show empty content(offline icon) for all optimistic attachments

Wdyt?

When you close the app on add attachment modal, I think user will have to reopen the flow. Anyways, as I said, we will revisit this after we are done saving attachments in different PR, if needed.

Let's break it down to smaller PRs to faster completion.

Okay, I will do this in the next PR

parasharrajat · 2025-06-08T15:16:43Z

src/libs/actions/Report.ts

+    if (file) {
+        parameters.attachmentID = attachmentID;
+    }
+


We need to pass this to get the data-attachment-id attribute inside the attachment tag i.e <img src="..." data-attachment-id="1234..." />

For markdown text link attachments, we will use the reportActionID + index

We need to pass this to get the data-attachment-id attribute inside the attachment tag i.e

Why do we need to do this? Does it handle the optimistic case?

It's used for storing and retrieving the attachment from Onyx/CacheAPI by using the data-attachment-id attachment_{idHere}

parasharrajat · 2025-06-08T15:20:06Z

src/types/onyx/Attachment.tsx

+    attachmentID: string;
+
+    source?: string;
+
+    remoteSource?: string;


Missing properties comment.

parasharrajat · 2025-06-09T15:27:17Z

src/libs/actions/Attachment/index.native.ts

+        return;
+    }
+
+    RNFetchBlob.config({fileCache: true, path: `${RNFetchBlob.fs.dirs.DocumentDir}/${attachmentID}`})


I don't think we need to worry about the attachment preview when the user is uploading the attachment. Until it is sent, we don't have to save it for offline preview. If needed we would do that later in different PR.

parasharrajat · 2025-06-09T15:48:29Z

@NJ-2020 Thanks for your work on this, and remain committed while we were discussing it. Can you please speed up the implementation? I believe we will have to go through a few iterations before we complete this task. Thus, it is important to update daily.

NJ-2020 · 2025-06-10T03:07:21Z

Okay, sure

NJ-2020 · 2025-06-10T13:36:14Z

PR will be ready tomorrow

I am still working on the unit test file

NJ-2020 · 2025-06-11T10:17:46Z

There's some issues while creating the unit test file
Will share an update when it's done

NJ-2020 · 2025-06-12T03:57:10Z

PR is ready

cc: @parasharrajat

NJ-2020 · 2025-06-15T12:34:15Z

Bump @parasharrajat for review

parasharrajat · 2025-06-12T13:20:44Z

src/libs/CacheAPI/index.ts

+        if (!key) {
+            return;
+        }


throw an error instead if key is not from passed CACHE_API_KEYS in init

parasharrajat · 2025-06-12T13:22:02Z

src/libs/CacheAPI/index.ts

+    if (!cacheName || !key || !value) {
+        return;
+    }


We don't have to check for these when all of them are required params. Please define the type in in App Response.

Also, add a logic that key is from CACHE_API_KEYS as this will allow overriding the settings passed in init.

Also, add a logic that key is from CACHE_API_KEYS as this will allow overriding the settings passed in init.

Done

We don't have to check for these when all of them are required params. Please define the type in in App Response.

Regarding this, CacheAPI only allow response value type, in this case the return response value returned from the fetch API, so I think defining our own response type definition I think it may can lead to typeerror or unmatch type with certain urls, wdyt?

its fine to use standard type.

parasharrajat · 2025-06-12T13:24:05Z

src/libs/CacheAPI/index.ts

+    if (!keys || keys.length === 0) {
+        return;
+    }


we should not pass any keys here instead they should be taken from the keys passed in init.

parasharrajat · 2025-06-12T13:24:30Z

src/libs/CacheAPI/index.ts

+        return cache.match(key);
+    });
+}
+function remove(cacheName: string, key: string) {


What is the cacheName?

cacheName is individual key in the lists of CACHE_API_KEYS

Let's keep this cacheName internal in the cacheAPI.

parasharrajat · 2025-06-15T12:58:46Z

src/components/AttachmentPicker/index.native.tsx

                };
            }) as [FileToCopy, ...FileToCopy[]],
-            destination: 'cachesDirectory',
+            destination: 'documentDirectory',


Do we need this change now?

Yes, because the caches directory will automatically cleared out when the app is closed which prevents the user to see the attachment when re-opening the app again

parasharrajat · 2025-06-15T13:27:38Z

tests/unit/AttachmentStorageTest.ts

+        global.fetch = TestHelper.getGlobalFetchMock();
+    });
+
+    it('should store for file in Onyx', async () => {


Add tests for:

Delete the attachment.

Change of remote source should reflect the change in local source.

After attachment is stored, you should confirm whether it was cached or not. Have tests for both Native and web.

I will create the unit test file after all the changes are done

Let's add it now. It is to validate that your changes work so as you go along updating this implementation the tests should also pass.

parasharrajat · 2025-06-15T13:28:40Z

tests/unit/AttachmentStorageTest.ts

We follow strict naming, so please move this to tests/actions/AttachmentTest.ts if you action file is called Attachment.

parasharrajat · 2025-06-15T13:29:54Z

src/types/onyx/Attachment.tsx

+    attachmentID: string;
+
+    /** Source url of the attachment either can be local or remote url */
+    source?: string;


Why would this source be remote? Should the remoteSource be remote? we should make sure this property always reflect local source and remoteSource remote.

Sorry may bad, done, fixed

parasharrajat · 2025-06-15T13:31:38Z

src/libs/actions/Session/index.ts

    NetworkConnection.clearReconnectionCallbacks();
    SessionUtils.resetDidUserLogInDuringSession();
    resetHomeRouteParams();
+    CacheAPI.clear([CONST.CACHE_API_KEYS.ATTACHMENTS]);


Could this slow down the signout process when there are many resources to be removed?

I've tried measuring the logout function performance using like this:

function cleanupSession() { const startTime = performance.now(); Pusher.disconnect(); Timers.clearAll(); Welcome.resetAllChecks(); MainQueue.clear(); HttpUtils.cancelPendingRequests(); PersistedRequests.clear(); NetworkConnection.clearReconnectionCallbacks(); SessionUtils.resetDidUserLogInDuringSession(); resetHomeRouteParams(); CacheAPI.clear(); clearCache().then(() => { const endTime = performance.now(); const duration = endTime - startTime; // console.log... }); clearSoundAssetsCache(); Timing.clearData(); }

And here's the result using 5 attachments video, for each video the size is: 14.3MB and the total is 71.5MB :

Without clearing CacheAPI With clearing CacheAPI

Duration: 174ms 245.8ms

That's a lot. So if a user keeps on using the app for a long time and logs out, the app might take seconds to log out.

Yes, so I think for alternative solution, I think we can clear the cache api when the user is on the login page or inside the PublicScreens, by using this way it will not affect the logout process, wdyt?

No a good idea. Maybe we leave it as it is. When a user uninstalls the app, whether the cache is cleaned or not?

We might need to add an option in the app to clean the storage manually.

When a user uninstalls the app, whether the cache is cleaned or not?

I am not sure about about uninstalling the app, because I don't know if the native os is deleting the entire app including the media folder which will also delete the attachment files

But for web if we don't clear the data/attachments on signout process, the data will keep saved until the user removes completely from their application storage

We might need to add an option in the app to clean the storage manually.

Yes, and I think maybe we can also implement like maybe storage management?

parasharrajat · 2025-06-15T13:38:23Z

src/libs/actions/Report.ts

+    });
+
+    attachments.forEach((attachment) => {
+        storeAttachment(attachment.attachmentID, attachment.uri ?? '');


There is a problem with code, what if the message failed to send the image will still be cached. we should follow optimistic patterns here.

you should update Onyx store values in optimisticData, successData and failureData. Same for delete attachment. Now this can be little tricky let's see what options do we have.

We can do auto cleanup and save when a attachment key is updated in Onyx.
we have a subscription to attachment collection which will update whenever we make changes to it so when you add a new attachment with remoteSource and attachmentID, we can update the cache to save the remote source and same for delete, we can remove the cache. This way cache will always be in sync with Onyx. This is just an idea and I am not sure how fast would it be. Please suggest yours also.

That's why I was thinking we save attachments report basis so we can subscribe to only attachment of visible report.

We need to consider this case. It is important app concept.

I think for Onyx we can solve it by passing into optimisticData, successData and failureData

But regarding CacheAPI it seems a little bit tricky, I am not sure regarding the subscribtion solution because we have to manage the Onyx and CacheAPI consistent in each other and make sure it runs smoothly

Please suggest yours also

IMO, I think we can introduce new method prop function inside libs/API onSuccess and onFailure
Here's an example

API.write(commandName, parameters, { optimisticData, successData, failureData, onSuccess: () => {}, onFailure: () => { /** remove attachment from CacheAPI */ }, });

Wdyt?, we can improve this later

IMO, I think we can introduce new method prop function inside libs/API onSuccess and onFailure
Here's an example

We can't do that. It is against our architecture. We need to find a way to do this. But we can focus on it later.

parasharrajat · 2025-06-15T13:40:02Z

src/setup/index.ts


+    const CacheAPIKeys = Object.values(CONST.CACHE_API_KEYS);
+
+    CacheAPI.init(CacheAPIKeys);


let's pass CONST.CACHE_API_KEYS it array to init function to pass CONST.CACHE_API_KEYS directly this function and then handle getting keys inside the function.

I left a very confusing commen. Sorry about that. What i meant to say was that we should pass CONST.CACHE_API_KEYS directly to the init function or send specific keys are array.

eg.

As object

CacheAPI.init(CONST.CACHE_API_KEYS)

As array

CacheAPI.init([Key1, Key2]);

But I am fine with the current logic where you are directly accessing them inside the function as we do not have any other keys currently for cache.

Oh, okay, thank you

parasharrajat · 2025-06-15T13:40:50Z

src/CONST/index.ts

+        ATTACHMENT: /<(img|video)[^>]*>/gi,
+        ATTACHMENT_ID: /data-attachment-id=(["'])(.*?)\1/,
+        ATTACHMENT_SOURCE_ID: /chat-attachments\/(\d+)/,
+        ATTACHMENT_SOURCE: /(src|data-expensify-source|data-optimistic-src)="([^"]+)"/i,


This is somewhat confusing. Can you please add comments to explain use of each regex.

parasharrajat · 2025-06-16T11:56:26Z

src/libs/CacheAPI/index.ts

+    if (!('caches' in window)) {
+        throw new Error('Cache API is not supported');
+    }
+    const keys = Object.values(CONST.CACHE_API_KEYS);


Ah, maybe I wan't clear. We have to use keys passed in parm but this is fine for now.

NJ-2020 · 2025-06-22T13:00:48Z

Bump @parasharrajat for above comments ^

NJ-2020 · 2025-06-26T14:15:53Z

Bump @parasharrajat

parasharrajat · 2025-06-26T14:37:12Z

I will start testing this tomorrow.

NJ-2020 · 2025-07-01T22:28:08Z

Bump @parasharrajat

NJ-2020 · 2025-07-02T09:32:54Z

Really sorry, due to some reasons, I've to close this PR

New PR here: #65321 - I am unable to reopen this PR

NJ-2020 · 2025-07-02T09:34:11Z

Apologies for the confusion here

NJ-2020 and others added 13 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

NJ-2020 marked this pull request as ready for review June 8, 2025 14:40

NJ-2020 requested a review from a team as a code owner June 8, 2025 14:40

melvin-bot bot requested review from parasharrajat and removed request for a team June 8, 2025 14:40

NJ-2020 mentioned this pull request Jun 8, 2025

[Image][$1000] Improve NewDot image uploading experience, add large file support #9402

Closed

parasharrajat reviewed Jun 8, 2025

View reviewed changes

parasharrajat suggested changes Jun 9, 2025

View reviewed changes

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

21f59ee

add missing comments

60ed019

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

efeee2b

NJ-2020 and others added 3 commits June 12, 2025 10:05

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

parasharrajat suggested changes Jun 15, 2025

View reviewed changes

parasharrajat reviewed Jun 15, 2025

View reviewed changes

NJ-2020 added 2 commits June 16, 2025 16:47

fix some comments & issues

648c196

remove unnecessary checks

bf021da

parasharrajat reviewed Jun 16, 2025

View reviewed changes

NJ-2020 and others added 5 commits June 17, 2025 08:52

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

NJ-2020 added 2 commits June 27, 2025 10:02

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

22ddea1

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

0b9bde7

NJ-2020 closed this by deleting the head repository Jul 2, 2025

NJ-2020 mentioned this pull request Jul 3, 2025

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

Merged

53 tasks

	const thumbnailImageComponent = (
	<ThumbnailImage
	previewSourceURL={processedPreviewSource}
	style={styles.webViewStyles.tagStyles.img}
	isAuthTokenRequired={isAttachmentOrReceipt}

	function getAttachmentSource(attachmentID: string, currentSource: string) {
	if (!attachmentID) {
	return;
	}
	const attachment = attachments?.[`${ONYXKEYS.COLLECTION.ATTACHMENT}${attachmentID}`];

	if (attachment?.remoteSource && attachment.remoteSource !== currentSource) {
	storeAttachment(attachmentID, currentSource);
	return currentSource;
	}


		const CacheAPIKeys = Object.values(CONST.CACHE_API_KEYS);

		CacheAPI.init(CacheAPIKeys);

Conversation

NJ-2020 commented Jun 7, 2025 • 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

Uh oh!

melvin-bot bot commented Jun 8, 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!

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!

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!

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

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!

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!

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!

parasharrajat commented Jun 9, 2025

Uh oh!

NJ-2020 commented Jun 10, 2025

NJ-2020 commented Jun 7, 2025 •

edited

Loading

NJ-2020 Jun 10, 2025 •

edited

Loading

parasharrajat Jun 12, 2025 •

edited

Loading