Investigate: job resume records no effects, so RecordEffect and EffectApplied have never run #824

New issue

Closed

opened 2026-08-15 17:07:41 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-15 17:07:41 +00:00

Member

Filed by Delphi (design seat) at Kai's instruction, 2026-08-15. Split from #621.

One issue for two functions, deliberately. Kai asked for an issue per capability. RecordEffect and EffectApplied are the write and read halves of one mechanism and neither is meaningful without the other, so splitting them would produce two tickets that can only be closed together. Saying so rather than silently merging.

The artifacts

RecordEffect     jobsubmit.go   marks a job step applied, for resume
EffectApplied    jobsubmit.go   reports whether a step already ran

The live consequence

Nothing in jobrunner.go records an effect. So job.Effects is empty for every job that has ever run, and a resumed job redoes every step it already completed.

That is not dead code with no cost. It is a property jobs plausibly need, with the only implementation present and unwired. It is also the direct cause of AttributeEffects being dead on #620.

What to establish

Is redo-on-resume actually harmful today? Depends entirely on whether any job step is non-idempotent. Enumerate the steps and say. If every step is idempotent, this is latent rather than broken and the urgency changes.
Read the commit that introduced them, and whatever job-resume design it referenced.
Whether Temporal changes the answer. #430 puts Deep's turns on Temporal with event history as the durable record, and jobs are explicitly out of scope for August 19. If jobs move to Temporal afterwards, this mechanism is replaced rather than wired, and building it now would be work with a known expiry.

Outcome

Wired, deleted, or recorded as superseded by Temporal - with the reason written down. Angie's framing stands: this is more likely unwired than abandoned, and deleting it removes the only implementation of something jobs probably need.

Parent - #621. Related - #620 (AttributeEffects), #430 (Temporal scope), coilyco-bridge/deploy#391 (durable job store).

Filed by Delphi (design seat) at Kai's instruction, 2026-08-15. Split from #621. **One issue for two functions, deliberately.** Kai asked for an issue per capability. `RecordEffect` and `EffectApplied` are the write and read halves of one mechanism and neither is meaningful without the other, so splitting them would produce two tickets that can only be closed together. Saying so rather than silently merging. ## The artifacts ``` RecordEffect jobsubmit.go marks a job step applied, for resume EffectApplied jobsubmit.go reports whether a step already ran ``` ## The live consequence **Nothing in `jobrunner.go` records an effect.** So `job.Effects` is empty for every job that has ever run, and **a resumed job redoes every step it already completed.** That is not dead code with no cost. It is a property jobs plausibly need, with the only implementation present and unwired. It is also the direct cause of `AttributeEffects` being dead on #620. ## What to establish 1. **Is redo-on-resume actually harmful today?** Depends entirely on whether any job step is non-idempotent. Enumerate the steps and say. If every step is idempotent, this is latent rather than broken and the urgency changes. 2. **Read the commit that introduced them**, and whatever job-resume design it referenced. 3. **Whether Temporal changes the answer.** #430 puts Deep's turns on Temporal with event history as the durable record, and jobs are explicitly out of scope for August 19. If jobs move to Temporal afterwards, this mechanism is replaced rather than wired, and building it now would be work with a known expiry. ## Outcome Wired, deleted, or recorded as superseded by Temporal - with the reason written down. Angie's framing stands: this is more likely unwired than abandoned, and deleting it removes the only implementation of something jobs probably need. **Parent** - #621. **Related** - #620 (`AttributeEffects`), #430 (Temporal scope), coilyco-bridge/deploy#391 (durable job store).

coilyco-ops referenced this issue

2026-08-15 17:08:03 +00:00

Four unwired capabilities are undocumented, so deleting them is a judgement someone else should make #621

coilyco-ops added the

autonomy

headless

priority

labels

2026-08-15 17:22:37 +00:00

coilyco-ops added the

role/engineer

label