Page Profiler transient reads still trigger “Commands out of sync” during shutdown

从 inc/manager.php、inc/v2/PageProfiler/Profile.php 和 inc/v2/PageProfiler/Storage/Transients.php 开始，跟踪 shutdown buffering 直到 transient 读取。运行 tests/test-lazyload-viewport.php，然后在 Optimole 4.2.10 上启用 Page Profiler 和 transient storage 进行复现，同时检查 shutdown 顺序和 output-buffer 状态。当确定触发问题的连接状态、shutdown 路径不再输出这些错误，并且 coverage 覆盖相关的集成用例时，即可视为完成。

Summary

Optimole can emit recurring WordPress database errors while processing frontend output during shutdown. Page Profiler transient reads are expected to complete without database errors, but the reported requests produce Commands out of sync; you can't run this command now messages for profile keys. The errors recur daily and fill the site’s error logs.

Customer context

• Product / area: Optimole WordPress plugin, Page Profiler and frontend output replacement
• Version: Customer’s installed version is unknown; inspected repository version is 4.2.10
• Environment: WordPress with profiler data stored in transients; the trace indicates no persistent external object-cache storage on this path
• Integration / third party: Unknown from available evidence
• Reported error / symptom: Repeated MySQL Commands out of sync errors during shutdown-time Page Profiler transient reads
• Impact: Daily database-error log growth on frontend traffic

Reproduction notes

Reported reproduction:

1. Serve normal frontend pages with Optimole output replacement and Page Profiler active.
2. Inspect the WordPress database-error log after page requests.
3. Observe repeated Commands out of sync entries for _transient__oprof_... reads whose stack runs through wp_ob_end_flush_all, Optimole’s output callback, and Page Profiler storage.

The failure was observed repeatedly in production logs but was not reproduced locally. The installed plugin version and the request condition that first desynchronizes the database connection were not provided.

Diagnosis

Conclusion

The reported runtime traces confirm that Optimole’s output-buffer callback reaches Page Profiler transient reads during WordPress shutdown and that those reads surface repeated MySQL Commands out of sync errors. The code contains the exact reachable call chain and transient-key format shown in the logs. This is a recurrence of the behavior tracked in closed issue #1014, now explicitly visible in Page Profiler storage. The evidence confirms the failing Optimole path, although it does not identify which earlier database operation first leaves the connection desynchronized.

Where this likely occurs

• Frontend output buffering: inc/manager.php — Optml_Manager::setup_replacer() lines 400–410 registers template buffering and close_buffer() on shutdown at PHP_INT_MIN.
• Shutdown replacement: inc/manager.php — Optml_Manager::process_template_redirect_content() and Optml_Manager::close_buffer() lines 793–826 install the output callback, invoke replace_content(), and flush the buffer.
• Profiler calls: inc/manager.php — Optml_Manager::replace_content() lines 441–473 calls Profile::exists_all(), Profile::missing_devices(), and Profile::set_current_profile_data() for full-page replacement.
• Profiler storage selection and reads: inc/v2/PageProfiler/Profile.php — Profile::__construct() lines 89–105 selects transient storage without a persistent external object cache; Profile::exists_all(), Profile::missing_devices(), Profile::exists(), and Profile::set_current_profile_data() lines 260–347 perform the reads represented in the trace.
• WordPress transient boundary: inc/v2/PageProfiler/Storage/Transients.php — Transients::get() lines 64–72 calls get_transient() with the _oprof_ prefix.
• History: commit 63b93a2c introduced shutdown buffer closure around v3.13.6. Commit bd94c770, merged as fcf052bf, changed the shutdown priority for #1014 and is present from v4.2.2 through the inspected v4.2.10. The current report postdates that release history.

Engineering notes

Closed issue #1014 covered the same user-visible database error during Optimole shutdown processing. Its mitigation only moved close_buffer() from default shutdown priority to PHP_INT_MIN; profiler and attachment-cache database operations remain inside output replacement. The current trace runs through wp_ob_end_flush_all into Optimole’s closure rather than showing Optml_Manager::close_buffer, suggesting that the priority mitigation was absent, bypassed, or unable to close the relevant buffer in the reported request. The customer’s installed plugin version is unavailable, so those alternatives cannot yet be separated.

The reported _transient__oprof_... queries align with transient-backed Page Profiler storage. The MySQL message also implies pre-existing connection state that is not identified by this stack; the evidence establishes where Optimole performs the failing query, not which component first leaves an outstanding result.

Test coverage status

tests/test-lazyload-viewport.php covers normal profiler behavior: test_lazyload_viewport() lines 63–85 invokes replace_content(), test_profile_data_storage_and_retrieval() lines 211–247 checks profile persistence, and test_viewport_data_exists_check() lines 302–311 checks exists_all(). Its storeMockProfileData() helper lines 487–505 also loads current profile data. No relevant coverage was found during inspection for close_buffer(), shutdown hook ordering, ob_end_flush(), nested output buffers, or a desynchronized database connection. PR #1021 added no automated test for its shutdown-priority change.

What to verify or explore next

• Reproduce on Optimole 4.2.10 with Page Profiler enabled, transient-backed storage, and frontend output buffering.
• Confirm the installed Optimole version associated with the supplied logs.
• Capture shutdown callback ordering and active output-buffer levels when wp_ob_end_flush_all invokes Optimole’s callback.
• Exercise requests where output is empty when the earliest shutdown callback runs and where later callbacks emit content.
• Run the profiler suites in tests/test-lazyload-viewport.php alongside a shutdown/output-buffer integration case.
• Compare behavior with and without a persistent external object cache.

Unknowns / follow-up

• The operation that initially places the MySQL connection in the out-of-sync state is not visible in the supplied stack.
• The customer’s exact WordPress, PHP, database, and Optimole versions are unknown.
• It is unknown whether another plugin or theme changes shutdown ordering or output-buffer state in the affected requests.

Confidence

Confidence: 88/100

Daily runtime traces repeatedly reach Optimole Page Profiler transient reads from the shutdown output-buffer callback. Repository inspection confirms that path remains reachable, while the priority-only mitigation that closed #1014 does not cover the observed trace; the exact installed plugin version and the component that initially desynchronizes MySQL remain unknown.

---

Source: HelpScout #3424946418
Generated by bug-report-triage (ID: bug-report-triage_6a87168d6b3146.68903490)