[waleedlatif1]

Summary

• The edit engine now remembers which operation's deferred connection created each edge, and when the end-of-batch scope check drops one of those edges (cross-subflow, trigger target, note endpoint), it charges that operation as declined. Before, a batch like add A with connections into a block inside a loop reported applied: 1 even though its only edge was removed and listed under skipped.
• Existing edges a move leaves crossing scopes (extract_from_subflow, insert_into_subflow) are still not charged. Losing them is the move's documented effect, not a refusal. Charging them is how the old skip-subtraction count could go negative.
• removeInvalidScopeEdges now returns the ids of the edges it dropped. Edge creation only appends, so each connection's new edges are the tail of edges after addConnectionsAsEdges.
• Follow-up to a release-review finding on fix(api): classify transient database reads and client-caused failures instead of answering 500 #9639's declinedOperationCount.

Type of Change

• Bug fix

Testing

• lib/workflows/editing/operations.test.ts: added a regression test where an add whose connection crosses into a loop counts as one declined operation. It failed before the fix (0 vs 1). Also added a guard test: extracting a block that leaves an existing edge crossing scopes counts as zero declined.
• operations.test.ts + apply-workflow-operations.test.ts: 71/71 pass
• Biome on the changed files. Type-check and audits are left to CI.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing (new tests pass the test-audit authoring gate)
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
docs	Skipped		Nov 4, 2026 9:35am UTC

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; no actionable issues were found.

Summary

The engine now counts an operation as declined when the final edge check removes an edge that operation created.

• Workflow edits count newly rejected connections against their requesting operation.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Apply operation handlers] --> B[Create deferred connections]
  B --> C[Record new edge IDs and their operations]
  C --> D[Resolve older pending connections]
  D --> E[Remove invalid edges]
  E --> F{Dropped edge has an operation?}
  F -->|Yes| G[Add operation to declined set]
  F -->|No| H[Leave declined count unchanged]
  G --> I[Return declined set size]
  H --> I

Loading

_{Reviews (1) · Last reviewed commit: "fix(workflows): charge an operation whos..." · Reviewed by Greptile}

[cubic-dev-ai]

No issues found across 2 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Turn on auto-fix | Re-trigger cubic}