[$250] Attachments - Markdown image URLs are not cached

[nlemma]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.3.39-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #65321
Email or phone of affected tester (no customers): applausetester+ap16@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11
App Component: Other

Action Performed:

1. Open the web app in Chrome.
2. Open browser DevTools.
3. Navigate to the Application tab.
4. Open Cache Storage and select “attachments”.
5. Log in with a valid account.
6. Navigate to any chat.
7. Click on the message composer.
8. Enter a markdown image URL (e.g. ![](https://images.unsplash.com/photo-1726066012751-2adfb5485977?w=100)).
9. Send the message.
10. Refresh the Cache Storage entries.
11. Search for the corresponding attachment entry.

Expected Result:

Markdown image attachments are stored in Cache API and available in the attachments storage.

Actual Result:

The markdown image is rendered in the chat.

No entry is created in Cache Storage for the attachment.

Directly uploaded image files are stored correctly, but markdown image URLs are not cached.

This creates inconsistent behavior between attachment types and affects offline availability.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

480353246-5596dd5c-780e-4e8b-940b-a35ebdc7ff05.mov

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @NJ-2020

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022033934689417948972
• Upwork Job ID: 2033934689417948972
• Last Price Increase: 2026-03-17
• Automatic offers:
• NJ-2020 | Contributor | 110867641

[MelvinBot]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Markdown image URLs (e.g., ![](https://images.unsplash.com/...)) sent in chat messages are rendered correctly but are not stored in Cache Storage. Directly uploaded image files are cached properly. This creates inconsistent offline availability between attachment types.

What is the root cause of that problem?

The App has two separate image caching systems on web, and markdown images fall through the cracks of both:

Cache System 1 — auth-images (display-side, used during rendering):
In ImageRenderer.tsx:50-52, the component checks for the data-expensify-source HTML attribute to determine if an image is an "attachment." Uploaded files get this attribute via getUploadingAttachmentHtml() in ReportUtils.ts:6345-6370, but ExpensiMark converts ![](url) to a bare <img src="url" /> without data-expensify-source (see ExpensiMark.js:201-204).

This means for markdown images: isAttachmentOrReceipt=false → isAuthTokenRequired=false → the Image component adds no auth headers → useCachedImageSource sees hasHeaders=false and returns the source unchanged, skipping the Cache API entirely.

Cache System 2 — attachments (sender-side, used during message send):
In Report/index.ts:745-768, when a user sends a message, the parsed HTML is scanned for <img> tags and cacheAttachment() is called for each. This does cache markdown images — but only on the sender's device. And critically, getCachedAttachment() is exported from Attachment/index.ts but is never called by any rendering component on web, making this cache write-only from a rendering perspective.

So: uploaded attachments get cached in auth-images during rendering (via auth headers). Markdown images get cached in attachments on send (sender only) but nothing reads that cache, and they're skipped by useCachedImageSource during rendering because they have no auth headers.

What changes do you think we should make in order to solve the problem?

Extend useCachedImageSource to also cache non-authenticated images when rendering chat images:

1. src/hooks/useCachedImageSource.ts — Accept an optional shouldForceCache parameter. When true, proceed with Cache API caching even without auth headers (using a plain fetch(uri) instead of fetch(uri, {headers})). Fall back to the original source if the fetch fails (e.g., CORS restrictions).

2. src/components/Image/index.tsx — Add a shouldForceCache prop. When isAuthTokenRequired is false but shouldForceCache is true, still include a cacheKey in the source object (set to the URI) so the hook knows to cache it, but omit auth headers.

3. src/components/HTMLEngineProvider/HTMLRenderers/ImageRenderer.tsx — Pass shouldForceCache={!isAttachmentOrReceipt} (or simply shouldForceCache={true}) through to ThumbnailImage for all chat images, so external markdown images also get Cache API caching.

This way, markdown images rendered in chat will be fetched, stored in auth-images Cache Storage, and served from cache on subsequent renders — matching the behavior of uploaded attachments. If the external server blocks CORS, the fetch will fail gracefully and the image will load via the browser's native HTTP cache (current behavior), so there's no regression.

What alternative solutions did you explore? (Optional)

• Use the existing attachments cache on the rendering side — Wire up getCachedAttachment() to the rendering pipeline. Rejected because the attachments cache is only populated on the sender's device; recipients never call cacheAttachment() for markdown images in received messages, so this wouldn't help the general case.

• Add data-expensify-source to markdown images in ExpensiMark — This would make them follow the same path as uploaded attachments. Rejected because these are external URLs that don't require authentication, and adding the attribute would incorrectly trigger auth token attachment for requests to external servers.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @ChavdaSachin (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022033934689417948972

[surafeal-dev]

Proposal

Please re-state the problem that we are trying to solve in this issue.

• Markdown image URLs sent in chat messages (e.g. ![](https://...)) render correctly in the web app but are not stored in Cache Storage. Directly uploaded image files are cached properly. This inconsistency prevents markdown images from being available offline and leads to divergent behavior between attachment types.

What is the root cause of that problem?

• The web app uses two distinct cache systems and markdown images miss both read paths:
  • Rendering-side auth-images (used when images include data-expensify-source and auth headers): Uploaded attachments get data-expensify-source, so useCachedImageSource fetches and caches them with auth. ExpensiMark converts markdown ![](url) to plain <img src="url" /> with no data-expensify-source, so these images bypass auth-images.
  • Sender-side attachments (used during message send): cacheAttachment() runs when sending messages and can cache images client-side for the sender. However, rendering components never call getCachedAttachment() on recipients, so recipients don’t benefit from this cache.
• Result: Markdown images are rendered from network (or browser HTTP cache) but are neither cached into the auth-images cache during render nor read from the attachments cache on recipients.

What changes do you think we should make in order to solve the problem?

• Goal: Ensure markdown/external images rendered in chat are cached on web during render (when possible) without adding auth headers or data-expensify-source.
• Implementation plan (code locations):
  • useCachedImageSource.ts
    • Add an optional shouldForceCache?: boolean parameter.
    • When shouldForceCache is true and no auth headers are present, attempt an unauthenticated fetch(uri) and store the response in the Cache API (use the existing auth-images cache namespace or a clearly named cache). If the fetch fails (CORS, network), fall back to returning the original source so the browser loads the image normally.
  • index.tsx
    • Add a shouldForceCache prop.
    • When isAuthTokenRequired is false but shouldForceCache is true, include a cacheKey (the image URI) in the source object so useCachedImageSource will attempt to cache it; do not attach auth headers.
  • ImageRenderer.tsx
    • Pass shouldForceCache={!isAttachmentOrReceipt} (or simply true for chat-rendered external images) to ThumbnailImage so markdown/external images trigger the caching path during render.
• Safety and behavior:
  • Do not add data-expensify-source or attach auth tokens for external URLs.
  • If CORS or other restrictions prevent programmatic caching, the hook fails gracefully and the browser’s native HTTP cache is used (no regression).
  • Use the image URL as the cache key to avoid collisions.

What alternative solutions did you explore? (Optional)

• Read the sender-side attachments cache during render (call getCachedAttachment()): Rejected because the attachments cache is only written on the sender; recipients would not benefit.
• Modify ExpensiMark to inject data-expensify-source on markdown images: Rejected because external URLs are not auth-protected and adding that attribute would incorrectly trigger auth headers.

Testing and verification

• Manual reproduce steps:
  1. Open web app in Chrome → DevTools → Application → Cache Storage → auth-images / attachments.
  2. Send a markdown image ![](https://images.unsplash.com/...).
  3. Confirm an entry is created in Cache Storage for that image after rendering.
  4. Open the message on a recipient device and test offline availability.
• Unit/integration tests:
  • Add tests for useCachedImageSource to simulate:
    • Successful unauthenticated fetch and cache write.
    • CORS failure leading to graceful fallback.
  • Snapshot or integration test to confirm ImageRenderer passes shouldForceCache for markdown images.

[melvin-bot]

📣 @surafeal-dev! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[surafeal-dev]

Contributor details
Your Expensify account email: surafealfasil6110@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~01f368b69f23b91e61?mp_source=share

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!