Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Attachment lookup cache can exhaust frontend request memory

Aperta
  • Qualcosa non va?
#1,139 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
55/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
php
Ambito
frontend, performance

Direzione di ricerca

Inizia da inc/attachment_cache.php e traccia le chiamate provenienti da inc/traits/dam_offload_utils.php e inc/url_replacer.php. Esegui tests/test-media.php, quindi esplora uno scenario di lookup orientato al volume con molti URL distinti entro un limite di 128 MB. Il lavoro è completato quando il percorso di lookup del frontend ha un limite verificato per la crescita della memoria e una copertura pertinente.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug-report bug-report-triage crash-report

Summary

Frontend image processing can terminate with an allowed-memory-exhausted fatal while resolving attachment IDs.

Expected behavior: Processing a page with many distinct image URLs completes within the request memory limit.

Actual behavior: The request can exhaust its memory limit during attachment-ID lookup.

Impact: Affected frontend requests fail before page output is completed.

Customer context

  • Product / area: Optimole attachment-ID lookup used by DAM/media offload processing
  • Version: 4.2.11
  • Environment: WordPress 7.1, PHP 8.1.2; 128 MB PHP memory limit reported
  • Integration / third party: Not provided
  • Reported error / symptom: Allowed memory size of 134217728 bytes exhausted at the attachment-ID lookup call
  • Impact: 8 occurrences across 2 production sites in the telemetry window

Reproduction notes

Reported production workflow: a frontend request on Optimole 4.2.11 reaches attachment-ID resolution and exhausts a 128 MB PHP memory limit.

Reproduction has not been run locally. A likely reproduction is a frontend response that causes media-offload URL processing for many distinct image URLs in one PHP request.

Diagnosis

Conclusion

The release code keeps each distinct attachment-URL cache key in Optml_Attachment_Cache::$cache_map for the lifetime of the PHP request and provides no size limit or automatic clearing path. The crash occurs at the call that enters this cache during frontend image processing. This is a confirmed unbounded per-request memory-growth path; the telemetry does not reveal the number or shape of URLs required to reach the reported 128 MB limit.

Where this likely occurs
  • inc/traits/dam_offload_utils.php — Optml_Dam_Offload_Utils::attachment_url_to_post_id() lines 284–332 calls the cache for each input URL, then caches the lookup result.
  • inc/attachment_cache.php — Optml_Attachment_Cache::get_cached_attachment_id() lines 27–40 inserts a value into the request-static $cache_map for cache misses; set_cached_attachment_id() lines 51–62 also inserts into that same map without a capacity boundary.
  • inc/url_replacer.php — Optml_Url_Replacer::is_offloaded_url() lines 430–450 reaches attachment_url_to_post_id() while processing an offloaded source URL.
  • The same cache behavior is present in tag v4.2.11. Git history attributes the cache lookup to 4c726ce1 (fix: cache calls to attachment_url_to_postid); no inspected tag comparison establishes a previously working bounded implementation.
Engineering notes

The cache is intentionally request-local, as documented in Optml_Attachment_Cache::get_cached_attachment_id() around lines 29–38, so it is released after a normal PHP request. Its growth is nevertheless proportional to the number of distinct processed URLs in a single request, including negative cache lookups. The affected frontend path can be reached when media offload is enabled through Optml_Url_Replacer::is_offloaded_url(). The available shutdown fatal lacks request HTML and a structured stack trace, so the exact page size and URL diversity remain unknown.

Test coverage status

tests/test-media.php covers normal attachment lookup variants in Test_Media::test_replace_alternative_domain() around lines 483–498 and resets the static cache before editor-content tests around lines 499–563. No relevant coverage was found during inspection for a large number of distinct attachment URLs in one request or for a memory-growth bound.

What to verify or explore next
  • May be worth reproducing frontend replacement with media offload enabled and a page containing an increasing number of distinct local and non-local image URLs under a 128 MB memory limit.
  • If reproducible, checking the peak size of the request-local attachment cache and whether cache misses contribute materially would close the telemetry context gap.
  • May be worth running the targeted tests/test-media.php suite alongside a volume-oriented lookup scenario.
Unknowns / follow-up
  • The telemetry has no structured stack trace or request payload, so the exact caller and number of distinct URLs at failure are not known.
  • No release boundary proving a regression was identified.

Confidence

Confidence: 87/100

One confirmed Optimole defect explains the DAM lookup memory-exhaustion fingerprint: the v4.2.11 release retains every unique attachment lookup in a request-static cache without an eviction boundary. The other four fingerprints do not currently establish a shipped defect: both required target files exist in the tagged release and match the autoloader path, the reported output-buffering location does not contain buffering calls in the locked SDK source, and the SDK-start memory fatal remains limited to one site without a trace showing an unbounded SDK allocation.

Crash telemetry
Occurrences 8
Distinct sites 2
First seen 2026-09-05 21:28 UTC
Last seen 2026-09-06 16:55 UTC
Crash location product:inc/traits/dam_offload_utils.php:285
Request context frontend
Inside Themeisle SDK no
Product versions 4.2.11
WP versions 7.1
PHP versions 8.1.2-1ubuntu2.25
SDK versions 3.3.61

Source: automated crash report — optimole-wp, fingerprint a031c89fdc3708fad35d577ae2cf94df
Generated by bug-report-triage (ID: bug-report-triage_6a9e53b43c3721.46530364)

Lingua principale
PHP
Stelle
73
Fork
14
Merge medio
2g 13h
PR unite (30g)
16

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Codeinwp/optimole-wp

Tutte le issue di Codeinwp/optimole-wp

Issue simili

Altre issue su PHP

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.