Skip to content

Commit 6a3e0dd

Browse files
committed
add issues
1 parent cc9a391 commit 6a3e0dd

File tree

1 file changed

+4
-1
lines changed

1 file changed

+4
-1
lines changed

.sudocode/issues.jsonl

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1 +1,4 @@
1-
1+
{"id":"i-4ygf","uuid":"ac0bbd62-bb4c-49cc-97c2-7dd2d34ffc41","title":"Extend workflow Block model for DAG metadata","content":"Update the base `Block` model in `skyvern/forge/sdk/workflow/models/block.py` to support the DAG metadata described in [[s-4bnl]].\n\n## Requirements\n- Ensure the Block dataclass / Pydantic model exposes the `id: str` field used for persistence (validate that it is present and documented).\n- Add/confirm a `label: str` field representing the author-facing identifier that must be unique per workflow; include validation helpers if necessary.\n- Introduce an optional `next_block_label: str | None = None` attribute so sequential blocks can point to the next block by label.\n- Update related DTO subclasses and serializers within the workflow SDK so the new attributes round-trip through API payloads.\n- Maintain backward compatibility for existing sequential workflows (e.g., default `next_block_label` derives from list order when absent).\n- Add or update tests covering serialization/deserialization of the new fields.\n\n## Definition of Done\n- `skyvern/forge/sdk/workflow/models/block.py` and dependent DTOs expose the new attributes with type hints and docstrings.\n- Validation enforces uniqueness/consistency where feasible without breaking legacy workflows.\n- Tests demonstrate that legacy workflows still deserialize without explicit `next_block_label` while new DAG-aware workflows do.\n- Any necessary documentation or comments reference the branching workflow spec.","status":"open","priority":2,"assignee":null,"archived":0,"archived_at":null,"created_at":"2025-11-14 06:25:27","updated_at":"2025-11-14 06:25:27","closed_at":null,"parent_id":null,"parent_uuid":null,"relationships":[],"tags":[]}
2+
{"id":"i-2hqk","uuid":"5fc0520f-4b49-44f1-9493-07807ef37fc8","title":"Add ConditionalBlock with BranchCondition and BranchCriteria scaffolding","content":"Implement the DAG branching models outlined in [[s-4bnl]] by introducing dedicated ConditionalBlock structures and branch metadata in the workflow SDK.\n\n## Scope\n- Extend `skyvern/forge/sdk/workflow/models` to add a `ConditionalBlock` model (building on the base Block hierarchy) that owns `branches: list[BranchCondition]`.\n- Create a first-class `BranchCondition` model with fields `id`, `criteria`, `next_block_label`, `description`, `order`, and `is_default`, ensuring serialization/deserialization coverage across DTOs.\n- Introduce a `BranchCriteria` abstraction that defines the interface for evaluating branch logic; for now only establish the interface contract plus stubs/hooks so we can later plug in Jinja templates, JSONLogic, pythonic expressions, or other engines.\n- Update relevant schemas, SDKs, and validators so conditional blocks and branches round-trip through storage and APIs while remaining backward compatible with existing sequential workflows.\n- Add tests validating branch ordering, default branch uniqueness, and serialization of conditional blocks.\n\n## Out of Scope\n- Choosing or implementing a specific BranchCriteria evaluation engine (Jinja/JSONLogic/python). Capture pros/cons analysis in a follow-up issue before implementation.\n","status":"open","priority":2,"assignee":null,"archived":0,"archived_at":null,"created_at":"2025-11-14 06:31:33","updated_at":"2025-11-14 06:31:33","closed_at":null,"parent_id":null,"parent_uuid":null,"relationships":[],"tags":["sdk","spec","workflow"]}
3+
{"id":"i-8wis","uuid":"c2e08d03-a116-420d-ad0d-641e142b99d1","title":"Refactor workflow execution engine for DAG traversal","content":"Update the workflow executor to follow the DAG semantics established in [[s-4bnl]] so workflows can branch via `next_block_label` and conditional branches.\n\n## Requirements\n- Introduce `workflow.entry_block_label` (or equivalent mechanism) and ensure legacy workflows default to their first block when the field is absent.\n- Refactor execution state to track `current_block_label` instead of list indexes, honoring `block.next_block_label` and conditional branches’ chosen edges.\n- Implement cycle detection/validation to guard against infinite loops; provide clear failure messaging when a cycle is detected.\n- Ensure failure handling, retries, and dependency resolution operate correctly when traversing the DAG rather than a flat list.\n- Persist run metadata that records the block label/id and any branch taken for observability and debugging.\n- Maintain backward compatibility: sequential workflows without explicit `next_block_label` should behave exactly as before.\n\n## Definition of Done\n- Execution engine code reflects DAG traversal with comprehensive unit tests covering sequential fallbacks, branching paths, validation failures, and branch auditing data.\n- Legacy workflows keep working without user changes, while new workflows can express branching paths that execute correctly.\n- Logging/metrics show which branch was taken to support analytics and debugging.\n","status":"open","priority":2,"assignee":null,"archived":0,"archived_at":null,"created_at":"2025-11-14 06:33:50","updated_at":"2025-11-14 06:33:50","closed_at":null,"parent_id":null,"parent_uuid":null,"relationships":[],"tags":["executor","workflow"]}
4+
{"id":"i-9pmm","uuid":"80bb0648-9ecd-4fca-bc2b-dee134e30287","title":"Update script generation and caching for branching workflows","content":"Align script generation and caching logic with the branching workflow design in [[s-4bnl]].\n\n## Requirements\n- Update the code that emits workflow execution scripts so it can represent `branches` as explicit `if/elif/.../else` blocks based on ordered `BranchCondition` definitions, routing to `next_block_label` targets.\n- Ensure generated scripts deterministically reference `workflow_permanent_id` and `block_label` so caching remains unique per node even when multiple paths converge.\n- Extend caching so newly visited block labels (including branch-specific paths) create entries keyed by `(workflow_permanent_id, block_label)` and can be reused on subsequent runs regardless of which branch led to them.\n- Reconcile executed block graphs after each run to persist cache entries for newly traversed branches while avoiding collisions with legacy sequential workflows.\n- Verify caching remains deterministic and branch-aware via tests that exercise multi-branch workflows.\n\n## Definition of Done\n- Script generation code outputs branch-aware control flow structures with ordered evaluation semantics.\n- Cache management recognizes DAG paths and maintains per-label entries.\n- Tests demonstrate deterministic script output/caching for workflows that include branching and legacy sequential behavior.\n","status":"open","priority":2,"assignee":null,"archived":0,"archived_at":null,"created_at":"2025-11-14 06:35:19","updated_at":"2025-11-14 06:35:19","closed_at":null,"parent_id":null,"parent_uuid":null,"relationships":[],"tags":["caching","scripts","workflow"]}

0 commit comments

Comments
 (0)