Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Workflow branch store and request-controller operation store grow without bound

Closed
  • Is something wrong?
#562 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
php, wordpress
Domain
backend, databases

Research direction

Examine the WP_Agent_Workflow_Branch_Store class and the request controller's operation store to understand their storage mechanisms. Look for the TTL_SECONDS constant and the forget_run() method. Identify where a sweeper could be added, perhaps via Action Scheduler. For the request controller, find the option key and operation array structure to implement pruning or splitting.

Written by the indexing model from the issue text.

Description

Problem

Two workflow stores grow without bound on a long-lived site. On a primary-mode Markdown-backed install used daily, after about two weeks:

  1. WP_Agent_Workflow_Branch_Store options are never swept.
    • 5,453 options accumulated: agents_wf_branch_* 3,247, agents_wf_branch_ctx_* 1,013, agents_wf_branch_index_* 1,013, agents_wf_branch_admission_* 180. The oldest is from 11 days earlier.
    • Rows carry expires (TTL_SECONDS = 7200), but expiry is only honoured on read. Rows are deleted only by forget_run() / forget_reconcile_receipt() when a run terminalizes, so any run that never resumes (stranded branches, crashed workers, a queue that stopped draining) leaves its rows forever.
  2. The request controller's operation store has no retention.
    • All operations for one controller key live in a single option. For one consumer's key it reached 9.9 MB.
    • That option is rewritten on each operation transition. On that backend, a write of this size measured about 1.5 s and a read about 48 ms, on every search the consumer runs.

Both costs scale with option count and size on any backend; they're just most visible on file-backed storage.

Suggested direction

  • Branch store: a bounded sweeper (for example, on the existing Action Scheduler recurring hook, or piggy-backed on dispatch) that deletes rows whose expires has passed and whose run is terminal or unknown.
  • Request controller: prune terminal operations past a retention window (and/or cap the count), and consider one option per operation, or a table, instead of one ever-growing array.

Related: storage-side latency fixes in Automattic/markdown-database-integration#429 make these writes cheaper, but don't remove the growth.

AI disclosure: measured and written up by Claude (Anthropic) via OpenCode/Kimaki at Chris Huber's direction.

Dominant language
PHP
Stars
33
Forks
8
Avg merge
24m
Merged PRs (30d)
18

Getting set up

We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Automattic/agents-api

All issues in Automattic/agents-api

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.