Plugin Directory: Delay trunk-only imports on tag-releasing plugins

[dd32]

Stacks on top of WordPress#631 to address the trunk-then-tag double-import problem.

The problem

Plugins that release from a tag commonly commit the version-bumped files to /trunk first and then svn cp trunk tags/X.Y shortly after — see r3530799 / r3530800 for a recent real-world example. Today the SVN watcher imports the trunk commit immediately: trunks Stable Tag points at the new version but /tags/X.Y does not exist yet, so the importer falls back to publishing the release from trunk (with the stable_tag_invalid_trunk_fallback warning). The follow-up tag commit then triggers a second import that re-publishes the same release from the tag.

The change

Reuses the merge model that this PR started with but expands it to cover this case. Plugin_Import::queue() now:

1. If a future event already exists for the plugin and no job is running, merge the new args into it (restoring merge_plugin_data() and the per-key OR/union behavior).
2. Decide the events run time from the merged args via a new queue_run_time() helper. If the result is a trunk-only update on a plugin whose current stable_tag is not trunk, run in 5 * MINUTE_IN_SECONDS; otherwise 5s.
3. Use min( existing_nextrun, queue_run_time(merged) ) so a pending event is never pushed further out.

That collapses two previously-separate rules into one:

• Bulk re-index pull-forward (this PRs current behavior): a far-future event merges with an arriving commit and runs at the usual time. Same outcome as before, just expressed as a merge.
• Trunk-then-tag delay (new): a trunk-only commit on a tagged plugin schedules at now + 5min. If the follow-up tag commit arrives within that window, it merges in — the merged args are no longer trunk-only, so queue_run_time() returns now + 5s and the event pulls forward to run as a single import that publishes from the tag. If no tag arrives, the event runs as scheduled and publishes from trunk-fallback, same as today (but only once).

Why stable_tag != trunk rather than tagged_versions

stable_tag is the directorys current view of where the plugin releases from; if its set to a version like 1.2.2, the next release is almost certainly going to come in via a tag. A plugin thats genuinely releasing from trunk (e.g. brand-new plugins, or those that never tag) keeps stable_tag = trunk and doesnt get delayed.

Edge cases

• Tag-touching commits, tag deletions, and plugins releasing from trunk run immediately — no behavior change.
• Brand-new plugin without a published stable_tag postmeta yet → no delay (the meta is falsy).
• An unrelated trunk-only bugfix that doesnt change Stable Tag → delayed 5 min, then runs and no-ops at import time. Harmless.
• Running job concurrency guard (last_scheduled + 1hr, or now + 1hr if a job is in flight) is preserved.

Changes

• Plugin_Import::queue() — unified merge model.
• Plugin_Import::queue_run_time() + Plugin_Import::is_trunk_only_update_on_tagged_plugin() — new run-time decision.
• Plugin_Import::merge_plugin_data() — restored from earlier in this PR.
• tests/Plugin_Import_Merge_Test.php — restored and expanded with cases for the trunk-only detection.

Test plan

• npm run plugins:test --filter Plugin_Import_Merge_Test — all merge + classification tests pass.
• In staging: with a plugin whose stable_tag is 1.0, commit a trunk-only change → verify an event is scheduled ~now + 5min. Then commit svn cp trunk tags/1.1 → verify the events args now include the tag and its nextrun pulled forward to ~now + 5s, then a single import runs and publishes from tags/1.1.
• In staging: with a plugin whose stable_tag is trunk (no tag history), commit a trunk-only change → verify the event is scheduled ~now + 5s (no delay).
• In staging: with a plugin whose stable_tag is 1.0, queue a bulk re-index event 30 min out, then trigger a commit-driven queue() → verify the event is pulled forward and the args merged (existing PR-631 behavior, unchanged).

🤖 Generated with Claude Code

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props dd32.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.