Bug: Bulk editing posts does not invalidate Redis Object Cache(post lists remai)

Environment Details

• WordPress Version: 7.1
• W3 Total Cache Version: Latest
• Object Cache Backend: Redis 8.6.6
• Server Stack: Nginx + PHP-FPM + Redis
• Active W3TC Modules: Page Cache(Enhancement), Object Cache (Redis), Browser Cache

Description

When bulk editing posts via the WordPress admin dashboard (e.g., selecting multiple drafts and changing their status to “Published”), the Redis object cache for WP_Query / post lists is not invalidated.

As a result, frontend archive pages, the homepage blog loop, and category lists continue serving the stale post list from Redis.Steps to Reproduce

1. Enable Object Cache in W3 Total Cache settings using Redis as the caching engine.
2. In WP Admin, navigate to Posts -> All Posts.
3. Select 2 or more draft posts via the checkboxes.
4. Select Bulk Actions -> Edit -> Apply.
5. Change Status to Published and click Update.
6. Visit the frontend homepage or blog archive in an incognito window.

Expected Behavior

The frontend post list / archive should immediately display the newly published posts, as the query cache holding the post lists should be invalidated upon status transition.Actual Behavior

• The newly published posts do not appear in the frontend loop.
• Individual posts are accessible directly via their permalinks, confirming they were successfully published in MySQL.
• The frontend query list remains stuck until Redis is manually flushed or invalidated.

Troubleshooting & Diagnostic Findings

To isolate the exact point of failure, I conducted the following tests:

1. Subsequent single-post update flushes the queue: If I edit and update any single post individually right after the bulk edit, the frontend post list immediately refreshes and displays all the previously bulk-published posts. This indicates that single-post save hooks trigger cache invalidation properly, whereas bulk editing skips or suppresses the invalidation signal.
2. Restarting Redis immediately forces a refresh: Restarting the Redis service (or executing redis-cli flushall) immediately resolves the issue and the frontend post list shows the updated posts. This confirms the stale query results are strictly held in volatile Redis memory rather than persistent database storage/transients.
3. Issue is strictly tied to Object Caching: Disabling Object Cache in W3TC completely resolves the issue. Frontend queries hit MySQL directly and reflect changes instantly after bulk editing.
4. Vendor-specific to W3TC’s Redis implementation: Keeping W3TC for Page Cache/Minify, disabling W3TC’s Object Cache, and switching to the standalone Redis Object Cache plugin completely resolves the issue. Bulk edits invalidate the post list immediately under the exact same server and Redis setup.

Core Refactor Suspicion & Technical Context

I recall that recent WordPress 7.x release notes highlighted major refactoring around the admin post list table (modernizing list architecture / Data Views / batch processing pipelines).

It is very likely that the updated post list table altered how batch updates and lifecycle hooks are dispatched during bulk operations:

• In modern WordPress, WP_Query caches results in the persistent object cache using posts_last_changed.
• If the refactored admin post list deferred standard save actions or routed bulk status changes through an optimized pipeline, legacy object cache listeners might fail to catch the batch event.
• As a result, wp_cache_set_posts_last_changed() is not invoked at the end of the routine, leaving the posts cache group’s last_changed key untouched in Redis while the MySQL records have already updated.

Could you please investigate compatibility with the refactored WP 7.x post list workflows and ensure a listener for bulk_edit_posts (or reliable execution of wp_cache_set_posts_last_changed()) is tied into the bulk update completion?