Save final state for runs; flexible input for "next" cron run#4531
Save final state for runs; flexible input for "next" cron run#4531taylordowns2000 merged 16 commits intomainfrom
Conversation
b6393ef to
581da7f
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4531 +/- ##
==========================================
- Coverage 89.55% 89.49% -0.07%
==========================================
Files 425 425
Lines 20344 20365 +21
==========================================
+ Hits 18220 18226 +6
- Misses 2124 2139 +15 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
@taylordowns2000 is this ready for review? |
It is, @midigofrank , but Stu's doing it with me this morning. Thanks for looking out :-) |
…xt-state # Conflicts: # test/lightning/invocation/run_test.exs
Security ReviewClaude hit the max-turns limit or encountered an error before posting findings. See the workflow run for details. |
Please look at this super quick slide show for quick context. When testing this PR, note that it goes best with OpenFn/kit#1306 so you can see the performance enhancements, but you're welcome to test on the current worker too.
Overview
This PR saves the run's final state and lets users choose which step's output the cron scheduler uses as input for the next execution. Closes #4485.
Final state preservation: When the worker sends run:complete, we now persist the run's final state by setting
final_dataclip_idon the runs table. Previously final_state was only used for webhook response broadcasting, then discarded. The handler accepts two mutually exclusive fields from the worker:Neither field is required — backward compatible with the current worker.
Cron input source: Each cron trigger now has an optional cron_cursor_job_id. When set, the scheduler uses that specific job's last successful step output. When null (the new default for fresh triggers), it uses the run's final_dataclip_id — the merged final state from above. A backfill migration points all existing cron triggers at their first downstream job, preserving current behavior.
Changes
cron_cursor_job_idFK on triggers → jobs, with backfill for existing cron triggersbelongs_to :final_dataclip;complete/2casts the new fieldresolve_final_dataclip/2either reuses an existing ID or inserts a new dataclip. Respectssave_dataclips: false. Wrapped in Repo.transactlast_state_for_job/1withInvocation.get_next_cron_run_dataclip/1, which branches oncron_cursor_job_id— eitherlast_run_final_dataclip/1(final run state) orlast_successful_step_dataclip/1(specific job output)manuallyUnselectedDataclipinstead of always being true in fullscreen modecron_cursor_job_idthrough Y.Doc and snapshotsPerformance considerations
final_dataclip_idpointing to the last step's output dataclip. Zero additional storage — just sets the FK.step:completewith the dataclip would be processed after therun:completewith a reference to the dataclip ID, but Claude tells me this isn't gonna happen... in a channel all events are processed in order.How to test
final_dataclip_idwill be null until the worker is updated (backward compatible)final_dataclip_idequals the last step'soutput_dataclip_id(no duplicate)final_dataclip_idpoints to a new dataclip with the merged outputfinal_dataclip_id; selecting a specific job uses that job's last successful step outputAI Usage
Please disclose whether you've used AI anywhere in this PR (it's cool, we just
want to know!):
You can read more details in our
Responsible AI Policy
Pre-submission checklist
/reviewwith Claude Code):owner,:admin,:editor,:viewer)