Image wrongly cached

[Its-Just-Nans]

Astro Info

Astro                    v5.13.8
Vite                     v6.3.6
Node                     v22.13.0
System                   Linux (x64)
Package Manager          npm
Output                   static
Adapter                  none
Integrations             none

If this issue only occurs in one browser, which browser is a problem?

All

Describe the Bug

During build I you have

src/
     imgs/
         folder1/
               image.webp
         folder2/
               image.webp

Both image.webp are exaclty the same

In my code I use some image but in different components with <img src={img.src} /> or with background url as inlined css

During build, the image will be optimized only once

 ▶ /_astro/image.CbqfUwcl_Zmidpi.webp (reused cache entry) (+3ms) (15/34)

but in the code both image will not have the correct filename

• <img src="/_astro/image.CbqfUwcl_Zmidpi.webp" ....
• ...background-image: url(/_astro/image.CbqfUwcl.webp);...

What's the expected result?

In the code both link should be correct and link to the image

Note: if i change the image it does not happen

cannot reproduce on stackblitz

Link to Minimal Reproducible Example

https://stackblitz.com/edit/github-hqqzmlsc-bw3vqhnu

Participation

• I am willing to submit a pull request for this issue.

[FredKSchott]

Note: this response was AI generated! We're trying out a new "AI Triage Bot" to see if it can help us triage the root cause of user-submitted bug reports. Feedback welcome!

Thanks for the clear report and repro notes!

What I think is happening

• Two local images with identical bytes but different source paths end up sharing the same emitted ESM asset name (Rollup dedup) like /_astro/image.<contentHash>.webp.
• When the same source image is run through Astro’s static optimization pipeline (getImage/Image component), a different filename is produced based on transform options, like /_astro/image.<contentHash>_<transformHash>.webp.
• Because our static-image bookkeeping currently derives the “original path” from the emitted ESM path (which has already lost the original directory info), different source files with the same content collapse to a single key. That can lead to mismatched filenames between:
  • raw ESM usage, e.g. background-image: url(${img.src}) → /_astro/image.<contentHash>.webp
  • optimized usage, e.g. <Image ...> or getImage() → /_astro/image.<contentHash>_<transformHash>.webp

Likely code area

• packages/astro/src/assets/vite-plugin-assets.ts
  • addStaticImageFactory() builds a key (finalOriginalPath) from the emitted ESM URL and stores transforms in globalThis.astroAsset.staticImages.
  • When identical-content files dedupe to the same ESM URL, different sources share one key.
• packages/astro/src/assets/utils/transformToPath.ts
  • propsToFilename() builds the transform filename. For ESM imports it uses dirname(filePath), but by then filePath is already an emitted/hashed path, so original directory info is gone.
• packages/astro/src/assets/build/generate.ts
  • Consumes the staticImages map to generate files and log “(reused cache entry)”.

Questions for the reporter

• How are you setting the background image?
  • Example: style="background-image: url(${img.src})" vs url('/src/imgs/folder2/image.webp') vs url(${(await getImage({ src: img, ...})).src})
• Are you using <Image>/<Picture>/getImage() anywhere for the same source image(s)?
• Can you run npm run build -- --clearCache and confirm if the mismatch persists?
• After build, which files exist in dist/_astro/ that begin with image.? Please list the exact filenames (especially whether both image.<contentHash>.webp and image.<contentHash>_<transformHash>.webp exist).
• Can you confirm the two source images are byte-identical (e.g., same checksum), not just visually identical?
• Do you have any Vite build.assetsFileNames customization or assetsPrefix/base settings?

Workarounds you can try now

• Use the same import/pipeline for both usages (either both as raw img.src or both via getImage()), so they pick the same filename.
• Give the two files different basenames (avoid both being image.webp) to avoid content-dedupe collision.
• Avoid mixing raw img.src in inline CSS with getImage() for the same underlying file.

Notes for maintainers (probable fix direction)

• Root cause: addStaticImageFactory() computes finalOriginalPath from the emitted ESM URL (post-dedup), erasing the original filesystem path. Different source files with identical content collapse to one staticImages entry.
• Proposals:
  • Key staticImages by the original filesystem path when available (we already receive originalFSPath in addStaticImageFactory()), not by the post-emit ESM URL. This preserves distinctions across folders while still allowing transform caching.
  • For ESM-imported images, pass/derive from options.src.fsPath when computing the key and when feeding propsToFilename() so folder context is preserved or at least uniqueness is guaranteed.
  • Alternative: include a stable source-path token in the transform hash inputs (hashTransform) or filename. This maintains content cache reuse while avoiding filename ambiguity.
• Touchpoints to inspect/change:
  • packages/astro/src/assets/vite-plugin-assets.ts (keying logic in addStaticImageFactory() and finalFilePath construction).
  • packages/astro/src/assets/utils/transformToPath.ts (propsToFilename() assumptions about filePath).
  • Add a test: two identical byte images in different subfolders, used once via img.src (inline CSS) and once via getImage(); assert both referenced filenames exist and resolve.

[Its-Just-Nans]

1. style="background-image: url(${img.src})"
2. No
3. I removed the cache and it was happening
4. The created was /_astro/image.CbqfUwcl_Zmidpi.webp missing was /_astro/image.CbqfUwcl.webp
5. Yes I did a sha256sum
6. no special config