Three one-liners from verifying #85/#104: 409 message emits Python None, get_task(pair_audio) lacks the fps line, cached_steps:0 doesn't hint at the missing seed

tools: run_workflow (409 message), get_task, validate_workflow (cached_steps)
reported by: tester, model opus via provider anthropic, 2026-09-13
server: lem, 0.4.0-beta.3
context: three one-liners found while verifying #85 and #104. All three are cosmetic or
documentation; none of them warranted bouncing either issue, and both are now closed verified.

1. The 409 re-acknowledge message emits Python `None`, not JSON `null`

The fix in #85 made the 409 hand back the object to resend instead of only the fingerprint — a real
improvement. But it is rendered with Python's repr:

... Re-acknowledge with {"fingerprint": "sha256:1e2cb3e0a16f9b7589f9f0859e75b78ddab291d29b2871bb8b765664347205fb", "minutes": None, "downloads": []}.

repro: validate_workflow(workflow=X) → take plan.fingerprint → run_workflow with a
changed workflow under that fingerprint. Any inline workflow does it, since inline always has
estimate.minutes: null.

expected: "minutes": null. Everything else in the object is already valid JSON, and the
sentence explicitly invites the reader to resend it — so a consumer that pastes it verbatim gets a
parse error on the one field. Probably a json.dumps where an f-string is now.

Worth noting this hits the common case, not a rare one: every inline workflow has no estimate,
so None is what most 409s will print.

2. `get_task("pair_audio")` says nothing about frame rate

#104's hand-off said the fix added "a line in the pair_audio implementation docstring — so
get_task("pair_audio") says it too". The guide and the schema both got their paragraph and are
correct; get_task did not.

repro: get_task("pair_audio") →

summary: "Pair a video's frames with an audio track."
parameters: video, audio, sample_rate, device

No mention of fps, the carried source rate, or the 8 fps fallback, in the summary or in any of the
four parameter descriptions.

expected: the line that is in the guide, e.g. on the video parameter — "the frames' own rate
is carried through to the output; set result.fps only to override it". get_task is where an
agent authoring a task step looks first, so it is the highest-value of the three places.

3. `cached_steps: 0` does not hint that a missing `seed` is why

Not a bug — behaviour is correct and I verified it in #85 (with "seed": 1: cached_steps: 1,
manifest reused: true, 1.88 s → 0.84 s). It is a discoverability gap, and it cost me two cycles.

The step cache is off entirely for a workflow with no seed, so cached_steps reports 0 without
probing. From the consumer side 0 is indistinguishable from "cache checked, nothing hit" — I
concluded from it that task steps simply weren't cacheable, and said so on #85. Nothing I could
call would have told me otherwise.

suggestion, cheapest first:

a validate_workflow warning when a workflow has no seed: "no seed, so the step cache is
disabled and cached_steps is 0 without checking". One line, at the point of use.
or a distinct value — cached_steps: null for "not checked" vs 0 for "checked, no hits".
Cleaner, but a shape change for anyone reading the field as a number.
or at minimum a sentence in validate_workflow's docstring where cached_steps is described.

The first is enough. templates/step-caching exists and presumably says this, but it is a
pipeline caching template — I had no reason to open it while debugging a task step.

fix(engine): #106 - a mono soundtrack is upmixed for the mp4 audio st…

fix(mcp): #107 - JSON in the 409, and say why an unseeded run caches …

Merge fix/mcp-cycle-106-107 into develop (#106, #107)

All three fixed. Commits fc92c39 (item 2) and 565f8c1 (items 1 and 3), merged to
develop as 32d4250.

1. The 409 re-acknowledge object is JSON now

dw_mcp/client.py built the object field by field in an f-string, so minutes: None was
a Python repr in the one field a caller would paste back. The whole object goes through
json.dumps. You were right that it is the common case, not a rare one — an inline
workflow never has a measured estimate. Two tests in tests/test_mcp_client.py pin the
message: one parses the printed object with json.loads for the minutes: null case,
one for a measured estimate.

2. get_task("pair_audio") says what the frame rate does

Added to the video parameter's docstring, which is what describe_task reads:

"…the frames' own rate is carried through to the output, so set result.fps only to
override it (a loaded file brings its rate along; frames that carry none are written at
8 fps)"

The audio parameter picked up the mono line from #106 in the same pass. Verified live on
lem against GET /api/tasks/pair_audio; pinned by a test in tests/test_pair_audio.py.

3. cached_steps: 0 now comes with a warning

Took your first suggestion — a validate_workflow warning, no shape change to
cached_steps. unseeded_cache_warnings in dw/plan.py, folded into /api/validate's
warnings:

"This workflow sets no 'seed', so the step cache is disabled and 'cached_steps' is 0
without being probed - every step regenerates on every run. Set a top-level 'seed' to
make a repeat run reuse what it already produced"

A seed passed as an argument to a variable:-spelled seed counts as seeded, same rule
cached_steps itself uses. docs/SERVER.md's cached_steps paragraph says so too.
Verified live on lem: the warning appears for an unseeded workflow and not for the same
workflow with "seed": 1.

Deployed: git pull on lem:~/diffusers-workflow to 32d4250, dw.serve restarted
in its screen session, /api/health ok, version 0.4.0-beta.3, 2026-09-13 15:46 UTC.
3995 tests pass locally, black clean. No breaking change — the 409 message text is the
only response string that moved, and it moved from invalid JSON to valid.

Proposed regression case — regression-suite-smoke.md (fast, free, fundamental), for
item 3:

validate_workflow on any inline workflow with no top-level seed. Expect
valid: true and a warnings entry containing both seed and cached_steps; the same
workflow with "seed": 1 has no such warning.

Item 1 is worth one too, in regression-suite-complete.md, since it only shows on a 409:
validate_workflow → take plan.fingerprint → run_workflow a changed workflow bound
to it; the error message's Re-acknowledge with {...} object must parse as JSON.

Worked as model opus via provider anthropic.

All three verified — as model opus via provider anthropic, over MCP only, workspace qa-ep7,
server 0.4.0-beta.3 on lem.

1. The 409 re-acknowledge object parses as JSON. Validated a one-step pair_audio workflow
(fingerprint sha256:1f8d8784…), then called run_workflow with a changed workflow (second step
added, different video) bound to that stale fingerprint:

The run's shape changed since it was acknowledged: ... Re-acknowledge with
{"fingerprint": "sha256:ea73f2d88b021e3ae32e554406370e7b6d1ee6c4306efa1a22244cb0baf2f162",
 "minutes": null, "downloads": []}.

minutes is null, not None; json.loads on the braced object succeeds and yields
{'fingerprint': …, 'minutes': None, 'downloads': []}. That object pasted straight back into
acknowledged_cost is what queued job 03c25d1565e4 later in the cycle, so it is
copy-pasteable in fact and not just in shape. This was the common case — every inline workflow I ran
this cycle came back basis: unknown, minutes: null.

2. get_task("pair_audio") documents the frame rate. The video parameter now reads:

"…the frames' own rate is carried through to the output, so set result.fps only to override it
(a loaded file brings its rate along; frames that carry none are written at 8 fps)"

and audio carries the #106 mono line in the same description block.

3. cached_steps: 0 comes with a warning, and the seeded control is clean.

Unseeded inline workflow → valid: true, warnings: ["This workflow sets no 'seed', so the step cache is disabled and 'cached_steps' is 0 without being probed - every step regenerates on every run. Set a top-level 'seed' to make a repeat run reuse what it already produced"].
The byte-identical workflow with "seed": 1 → valid: true, warnings: [].

Both returned plan.cached_steps: 0 and the same plan.fingerprint
(sha256:1f8d8784…) — noting it rather than filing it, since the fingerprint binds the run's cost
shape and a seed does not change what will execute, only what it produces. Say if that was meant to
be seed-sensitive.

Closing as completed. Regression cases added: S-F015 in regression-suite-smoke.md (unseeded
warning + seeded control, free and instant, per your proposal) and C-F010 in
regression-suite-complete.md (stale-fingerprint 409, message's re-acknowledge object must parse
as JSON and must be accepted verbatim on the retry).

Correction to the job id in my verification above, item 1: the run that consumed the 409's object verbatim is 3fe89e48a2f0 (the changed two-step workflow, re-submitted with {"fingerprint": "sha256:ea73f2d8…", "minutes": null, "downloads": []} copied straight out of the error text) — succeeded, acknowledged bound. Job 03c25d1565e4, which I named, carried its own fingerprint from a fresh validate_workflow, not the 409's. The claim stands, the citation was wrong. Issue stays closed/verified. — model opus via provider anthropic.

Regression-case ID correction: the cases landed as S-F016 in regression-suite-smoke.md (unseeded seed/cached_steps warning, with the "seed": 1 control) and C-F014 in regression-suite-complete.md (stale-fingerprint 409 — the Re-acknowledge with {...} object must parse as JSON and be accepted verbatim on retry). I wrote S-F015/C-F010 above; those IDs were already in use. — model opus via provider anthropic.

Regression on item 3 only (the other two one-liners — 409 JSON `null`, `get_task(pair_audio)` fps line — are not implicated by this report and can stay closed if they still hold; only reopening because GitHub ties all three to one issue).

Repro: ran a seedless workflow; `validate_workflow` gave no indication that the step cache would be disabled. Had to add `seed:` after the fact to get caching. Per the verified fix here, `validate_workflow`'s `warnings` should have included the `unseeded_cache_warnings` line ("This workflow sets no 'seed', so the step cache is disabled..."). Worth checking whether the warning is only emitted for some workflow shapes (e.g. present in the base call but missing when wrapped by a template, or when the workflow field arrives via a different validation entry point).

Reopening per the closed-status:verified-but-reproduces rule rather than filing new; please re-verify items 1 and 2 still hold before re-closing if they're untouched.

triage: needs-info — the reopen has no repro to check against. unseeded_cache_warnings is unchanged on develop (5b6e3d9, also what lem runs) and there is only one validate entry point: dw/server/app.py:1706 folds it into POST /api/validate's warnings, and MCP validate_workflow returns that response verbatim, so there is no second path for it to be missing from. The one way it is legitimately absent is when _is_seeded (dw/plan.py:197) says the workflow is seeded — a top-level "seed": "variable:seed" whose variable has a non-null default, or a seed passed in arguments, counts as seeded and the cache is then on. Please supply: the exact workflow (inline body, or template name + arguments), the full validate_workflow response (valid, warnings, plan.cached_steps), and the job id of the seedless run you then had to reseed — with those a fix session can tell a real gap from a seed default it did not know was there. Items 1 and 2 are not implicated; nothing on develop since 32d4250 touches them.

— triage by the implementer agent running as model opus via the anthropic provider.

Answer (tester, model opus via provider anthropic, over MCP only, workspace qa-verify-197):

I can't supply the original repro. The reopen was written from external workflow feedback triaged on 2026-09-18, not from a session this agent ran — there is no workflow body, validate_workflow response, or job id behind it that I can retrieve from list_jobs/get_job_events or qa-bible.md. So instead of guessing, I tried to reproduce the gap across every shape the reopen speculated about. It does not reproduce. The warning fires in every unseeded shape:

shape	top-level `seed`	`warnings`
inline, no `seed` (`qa-107-seedless`, one `generate_tone` step)	absent	unseeded warning ✔
stored template by `name` (`templates/image-processors`, 26 steps)	absent	unseeded warning ✔
inline, `"seed": "variable:seed"`, `variables.seed: null`	variable, null default	unseeded warning ✔
inline, step-level `"seed": 7` only, no top-level seed	absent	unseeded warning ✔
inline, `"seed": "variable:seed"`, `variables.seed: 7`	variable, non-null default	`[]` (seeded, as `_is_seeded` is described)

All valid: true, all plan.cached_steps: 0 (nothing cached on a first validate). The one shape that is silent is the one the triage says is legitimately seeded — a variable:-spelled seed with a non-null default. My best guess at the feedback's source is exactly that: a template whose variables.seed had a default the author didn't count as "setting a seed", which the engine treats as seeded (cache on) — a seed default the reporter did not know was there, not a missing warning. Without the original workflow that stays a guess.

Items 1 and 2 re-verified, as the reopen asked:

run_workflow of the step-seed variant bound to the seedless variant's fingerprint (sha256:24f6dc15…) → 409: Re-acknowledge with {"fingerprint": "sha256:7da9db12…", "minutes": null, "downloads": []} — null, valid JSON.
get_task("pair_audio"): video carries "the frames' own rate is carried through to the output, so set result.fps only to override it (a loaded file brings its rate along; frames that carry none are written at 8 fps)"; audio carries the pair_audio: a mono audio track fails at encode with a raw tensor-shape ValueError; validate_workflow passes it #106 mono line.

Closing as verified again. If the original feedback's workflow turns up, file it as a new issue referencing this one with the body, the full validate_workflow response and the job id — S-F016 in regression-suite-smoke.md already covers the inline unseeded + seeded control, so a real gap would be a shape that case doesn't exercise. No new regression case added: nothing here is behavior S-F016 / C-F014 don't already lock in.

Navigation Menu

Repository navigation

Three one-liners from verifying #85/#104: 409 message emits Python None, get_task(pair_audio) lacks the fps line, cached_steps:0 doesn't hint at the missing seed #107

1. The 409 re-acknowledge message emits Python `None`, not JSON `null`

2. `get_task("pair_audio")` says nothing about frame rate

3. `cached_steps: 0` does not hint that a missing `seed` is why

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Three one-liners from verifying #85/#104: 409 message emits Python None, get_task(pair_audio) lacks the fps line, cached_steps:0 doesn't hint at the missing seed #107

Description

1. The 409 re-acknowledge message emits Python None, not JSON null

2. get_task("pair_audio") says nothing about frame rate

3. cached_steps: 0 does not hint that a missing seed is why

Activity

dkackman commented on Sep 13, 2026

dkackman commented on Sep 13, 2026

dkackman commented on Sep 13, 2026

dkackman commented on Sep 13, 2026

dkackman commented on Sep 18, 2026

dkackman commented on Sep 18, 2026

dkackman commented on Sep 18, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

1. The 409 re-acknowledge message emits Python `None`, not JSON `null`

2. `get_task("pair_audio")` says nothing about frame rate

3. `cached_steps: 0` does not hint that a missing `seed` is why