Repository navigation
Flush the runtime object cache before each STDIO message - #413
softglazee wants to merge 2 commits into
Conversation
The STDIO server handles a whole session in one WP-CLI process, so the object cache kept what earlier messages read and tools returned stale data after changes made in WP Admin, cron or REST requests. Flush the runtime cache before each message. Persistent caches without runtime flush support are left alone, since wp_cache_flush() would empty the shared cache for the whole site. Fixes WordPress#409.
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. Props Bot commandsYou can trigger Props Bot actions by commenting on this PR:
|
There was a problem hiding this comment.
🟢 Approval recommended
The focused change matches the intended behavior, protects shared persistent caches, and includes relevant regression coverage.
No open issues 🎉
What changed in this PR
Addresses #409 by flushing the runtime object cache before each STDIO message, allowing the long-running server to read current data when runtime flushing is supported.
Changes:
- Flushes the runtime cache before decoding each message.
- Leaves caches without runtime-flush support untouched to protect shared persistent data.
- Adds regression tests for stale site-title reads and per-message cache clearing.
| File | Description |
|---|---|
tests/phpunit/Unit/Cli/StdioServerBridgeTest.php |
Adds regression coverage for fresh reads and cache clearing. |
includes/Cli/StdioServerBridge.php |
Adds a capability-guarded runtime cache flush before message handling. |
Review effort: Balanced
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## trunk #413 +/- ##
=========================================
Coverage 93.12% 93.13%
- Complexity 1382 1383 +1
=========================================
Files 59 59
Lines 4016 4018 +2
=========================================
+ Hits 3740 3742 +2
Misses 276 276
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
What?
Closes #409
The STDIO server now flushes the runtime object cache before it handles each message, so tools read current data.
Why?
wp mcp-adapter servehandles the whole session in one WP-CLI process, so the object cache lives as long as the session. Tools kept returning what they read first and missed changes made in WP Admin, cron or REST requests. An ability that checks current data before a write could check an old copy. The HTTP transport is not affected, since each call is its own request.How?
StdioServerBridge::handle_request()callswp_cache_flush_runtime()before it decodes each message, whenwp_cache_supports( 'flush_runtime' ). That clears the in-memory copy only, so a persistent cache such as Redis keeps its data and the next read gets the current value from it. A persistent cache that does not support a runtime flush is left alone, becausewp_cache_flush()would empty the shared cache for the whole site.The flush runs in
handle_request()rather than in the read loop, so it covers every message and the existing tests that callhandle_request()directly go through it too.New tests in
StdioServerBridgeTest:test_tool_call_reads_changes_made_by_another_process: calls a tool that returnsblogname, changes the title directly in the database (as another process would), and calls the tool again. On trunk it returns the old title.test_each_message_flushes_the_runtime_cache: a cached value is gone after oneping.Testing Instructions
wp mcp-adapter serve --server=mcp-adapter-default-server --user=admin.mcp-adapter-execute-abilitywith{"ability_name": "core/get-site-info", "parameters": {"fields": ["name"]}}. It returns the site title.Results on PHP 8.3 with WordPress trunk:
StdioServerBridge.php.Changelog Entry