perf(history): stop storing the request payload a third time - #4

What

Enqueueing writes the request payload three times:

getTaskHistory() and getTaskStats() only look at status and task_name. getTaskDetails() reads task:{id} and never touches history. So the third copy is written, held for TASK_HISTORY_RETENTION, and never used.

This PR strips payload from the history write only.

Why it matters

A generation carrying an inline base64 image pins three times its own size for a full retention window.

In production one caller pushed 17 requests of 11–17 MB in 30 seconds. The database returned:

OOM command not allowed when used memory > 'maxmemory'
Redis::rPush(): Send of 16923690 bytes failed with errno=32 Broken pipe

These databases are ~450 MB and many queues share one host, so the damage was not confined to that caller. Other server types began failing to enqueue with read error on connection, fell back to the direct-server path, and surfaced errors to unrelated users.

For reference, the database I could inspect was already doing everything right — maxmemory-policy=allkeys-lru, 102,548 keys already evicted, and a TTL on 6,296 of 6,297 keys. Eviction was not the missing piece; the volume was. Its key census also shows the duplication plainly: task 2,933 vs task_history 2,856, near 1:1.

What this does not fix

Multi-megabyte payloads should not travel through Redis at all. The durable fix is to upload them and enqueue a URL. This removes a third of the cost per request — the third that is pure retention — and buys headroom; it is not the cure.

Deliberately not stripped

• ml_tasks — the worker pops it and needs the args.
• task:{id} — requeueStuckProcessingTasks() rebuilds from it, so stripping here would silently requeue an argument-less job.

One coupling worth knowing about

The frontend resolves a finished generation through payload.data.args.0.output on whatever getTaskDetails() returns. That is safe only because getTaskDetails() reads task:{id}, which keeps its payload.

If getTaskDetails() is ever given a task_history:{id} fallback — and ModelQTest::testTaskHistoryWithErrorDetails already expects one — a stripped history would resolve those links to an empty array and report completed work as producing no output. The docblock says so at the point of the change.

Tests

New tests/Integration/TaskHistoryPayloadTest.php, 5 cases:

• history loses the payload (marker absent, payload key gone)
• history keeps the fields its readers use (status, task_name, task_id)
• queue and task:{id} still carry the payload — the control case
• history no longer scales with payload size
• getTaskStats() still reports the task

Targeted run: 5 passed, 12 assertions.

Mutation-tested: revert the unset() and 2 of the 5 go red; restore it and all pass.

Full suite is 142 tests, 13 failures — all pre-existing on main (ModelQTest payload-shape assertions, StreamingTest, WorkerTest). Confirmed by stashing this change and re-running: baseline is 15 failures, which is these same 13 plus the 2 new tests failing without the fix. PHPStan is 35 errors before and after, and does not flag the new method.

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}