Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Attachment lookup cache can exhaust frontend request memory

Đang mở
  • Có gì không ổn?
#1,139 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
55/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
php
Lĩnh vực
frontend, performance

Hướng nghiên cứu

Bắt đầu với inc/attachment_cache.php và truy vết các lệnh gọi từ inc/traits/dam_offload_utils.php và inc/url_replacer.php. Chạy tests/test-media.php, sau đó khám phá một kịch bản lookup theo khối lượng với nhiều URL khác nhau dưới giới hạn 128 MB. Được xem là hoàn tất khi đường dẫn lookup của frontend có giới hạn tăng trưởng bộ nhớ đã được xác minh và có coverage liên quan.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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)

Ngôn ngữ chính
PHP
Star
73
Fork
14
Merge trung bình
2 ngày 13 giờ
Pull request đã merge (30 ngày)
16

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của Codeinwp/optimole-wp

Tất cả issue của Codeinwp/optimole-wp

Issue tương tự

Thêm issue về PHP

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.