docs(flare-workflow): design-spec for typed/structured trigger params - #506
Merged
getappz merged 2 commits intoAug 15, 2026
Merged
Conversation
…#125) Compares Cloudflare Workflows' events-and-parameters doc against flare-workflow's start_workflow/MCP run boundary. The WaitEvent/ complete_event durable-wait mechanism already closely matches Cloudflare's waitForEvent/sendEvent, including documented event-buffering semantics. The real gap is upstream: no structured/typed initial payload reaches the MCP boundary, only a single opaque input string, and no auto-populated trigger metadata (timestamp, workflow name) exists on WorkflowContext. Recommends a parallel params: serde_json::Value channel journaled inside the existing Input entry (no schema migration), with {{params.x}} template support, as a ~60-90 LOC additive change. No code change made here; this records the concrete design for a follow-up implementation item. Agentflare-Agent: claude-code Agentflare-Branch: task/125-design-spec-typed-structured-params-for Agentflare-Item: 125
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 57 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
Comment |
getappz
changed the title
2 tasks
getappz
added a commit
that referenced
this pull request
Aug 19, 2026
) Two real bugs surfaced by CodeRabbit's review of PR #557: - The at-cap branch of handle_terminal_job_failure never restored assignee_agent after release_and_comment cleared it, so the cap comment's own instruction ("item action=redispatch") would fail with "no assignee_agent to redispatch to" unless the caller passed one explicitly. - consecutive_identical_failure_count treated neither a posted cap comment nor an unrecorded-outcome cycle (e.g. an orphan-restart via restore_ready_for_work, which deliberately posts no marker) as a streak boundary. A post-redispatch retry that failed with the same reason would immediately re-trip the cap with zero retry budget, and a benign daemon-restart gap could silently bridge two otherwise unrelated identical-reason cycles into a false consecutive streak. Fixed both, added regression tests for each, and reformatted with cargo fmt. Agentflare-Agent: claude-code Agentflare-Branch: task/506-cap-consecutive-identical-sdd-loop-dispa Agentflare-Item: 506
getappz
added a commit
that referenced
this pull request
Aug 19, 2026
…re auto-redispatching indefinitely (#557) * Adds a dispatch-attempt ceiling to the daemon's auto-redispatch loop, per the item's ask: after `DISPATCH_FAILURE_CAP` (3) consecutive dispatch cycles ending with the same normalized terminal failure reason, the daemon stops auto-redispatching and surfaces the item for manual/PM review instead of retry-looping indefinitely. - New `src/dispatch_failure_ceiling.rs`: parses `## supervisor — dispatched` / `## agentflare work — failed` / `## agentflare work — complete` comment markers into per-cycle failure reasons, counts the consecutive-identical streak (whitespace-normalized so formatting-only diffs still match), resets on a differing reason or a success. - `dashboard::orphan_reconcile::handle_terminal_job_failure` now checks the streak: below the cap, restores `ready-for-work` (unchanged behavior); at/above the cap, swaps to `needs-manual-dispatch` (or leaves it off `ready-for-work` if that label doesn't exist) and posts a `## supervisor — identical failure cap reached` comment with the last failure reason, so a human knows to `item action=redispatch` after fixing the root cause. - `supervisor::dispatch_item` now emits its dispatch-marker comment via a shared constant instead of an ad hoc string literal, so the ceiling's comment-parsing can't silently drift out of sync. `cli::work::release_and_comment`'s failure-marker stays a literal string (a comment there documents the sync requirement) rather than importing the constant, because `src/cli/work.rs` is LOC-frozen at exactly 2100 lines and any net-positive change to it is rejected by the repo's LOC gate. - Also fixed the same label/assignee-restore ordering bug in `handle_terminal_job_failure` that a same-day review found in the sibling `restore_ready_for_work` function (separate PR #556, unmerged as of this writing): `assignee_agent` is now restored before the `ready-for-work` label is added, so a DB failure between the two calls can't strand the item labeled-ready-but-unassigned (item #150's failure class). This continues WIP a prior cursor dispatch on this item left uncommitted in the worktree (real progress — the core module and its 5 unit tests were already correct and unchanged here). I reviewed it, fixed a clippy `collapsible_if` lint and a formatting nit, applied the ordering fix above, unstaged an unrelated LOC-over-budget hunk on `work.rs` that was staged from the earlier attempt, and verified: `cargo build --lib`, `cargo clippy --tests -- -A unsafe_code -A clippy::pedantic -D warnings`, and `cargo fmt --check` all clean; `dispatch_failure_ceiling::tests` (5/5), `dashboard::orphan_reconcile::tests` (10/10, including 2 new cap-behavior tests), and `supervisor::tests` (28/28) all pass. * fix(work): address CodeRabbit findings on the dispatch failure cap (#506) Two real bugs surfaced by CodeRabbit's review of PR #557: - The at-cap branch of handle_terminal_job_failure never restored assignee_agent after release_and_comment cleared it, so the cap comment's own instruction ("item action=redispatch") would fail with "no assignee_agent to redispatch to" unless the caller passed one explicitly. - consecutive_identical_failure_count treated neither a posted cap comment nor an unrecorded-outcome cycle (e.g. an orphan-restart via restore_ready_for_work, which deliberately posts no marker) as a streak boundary. A post-redispatch retry that failed with the same reason would immediately re-trip the cap with zero retry budget, and a benign daemon-restart gap could silently bridge two otherwise unrelated identical-reason cycles into a false consecutive streak. Fixed both, added regression tests for each, and reformatted with cargo fmt. Agentflare-Agent: claude-code Agentflare-Branch: task/506-cap-consecutive-identical-sdd-loop-dispa Agentflare-Item: 506
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Design-spec (docs only, no code change) comparing Cloudflare Workflows' events-and-parameters model against flare-workflow's start_workflow/MCP run boundary. WaitEvent/complete_event already closely matches waitForEvent/sendEvent (incl. documented event-buffering). The actual gap: no structured/typed initial payload reaches the MCP boundary (only an opaque
input: String), and no auto-populated trigger metadata (timestamp, workflow name) on WorkflowContext. Recommends a parallelparams: serde_json::Valuechannel journaled inside the existingInputentry (no migration) plus{{params.x}}template support — ~60-90 LOC, additive only. Seecrates/flare-workflow/TYPED_PARAMS_DESIGN.md.