test: add more flow example#445
Conversation
leavesster
commented
Jan 30, 2026
- test: add progress flow to validate report_progress API
- test: add warning flow to validate BlockWarning on undefined output handle
- test: add nullable flow to validate nullable input handling
- test: add subflow-progress flow to validate BlockProgress events in subflows
- test: add from flow to validate inputs_from modes
- test: add additional-block flow to validate dynamic inputs/outputs
- test: add test cases for progress, warning, nullable, subflow-progress, from, and additional-block flows
- test: strengthen test assertions for progress, from, and additional-block flows
- fix: update searchPaths to use array instead of string
Add test flow that calls context.report_progress() 4 times with values 0, 25, 50, 75 to verify BlockProgress events.
…andle When a block returns an output key not defined in outputs_def, the SDK should emit a BlockWarning event. This test returns 'c' when only 'a' and 'b' are defined.
Adds test flow that verifies inputs with nullable: true can accept null/empty values. First node validates input is None, second node receives output from first node plus its own nullable input.
…ubflows Add test case with a subflow containing 2 nodes that each report progress 4 times (0%, 25%, 50%, 75%), generating at least 8 BlockProgress events total. The main flow calls the subflow and passes output to an end node.
Tests three inputs_from connection types: - value: direct input value (input=2) - from_node: output from another node (+python#2 outputs 3) - value+from_node: value node (+value#1=4) with fallback value (5) Expected result: 2 + 3 + 4 = 9
Add a block with additional_inputs: true and additional_outputs: true to test dynamic input/output handling at node level.
…s, from, and additional-block flows Add 6 new test cases to flow.test.ts: - progress: validates BlockProgress events and output count - warning: validates BlockWarning message on undefined handle - nullable: validates nullable input handling - subflow-progress: validates BlockProgress in subflows (>=8 events, all in [0,100]) - from: validates from_node, value, and value node inputs - additional-block: validates dynamic inputs/outputs
…lock flows - Add BlockProgress event validation to progress test - Add output value assertion (9) to from flow test - Add merged output assertion (helloworld) to additional-block test
The new @oomol/oocana 0.24.1 expects searchPaths as an array
Summary by CodeRabbit版本说明
✏️ Tip: You can customize this high-level summary in your review settings. Walkthrough新增多个工作流示例、相应的 Python 脚本与子流定义,并扩展端到端测试覆盖(progress、warning、nullable、subflow-progress、from、additional-block);测试中将 runFlow 的 Changes
预估代码审查工作量🎯 3 (Moderate) | ⏱️ ~20 分钟 🚥 Pre-merge checks | ✅ 1 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
There was a problem hiding this comment.
Pull request overview
This pull request adds multiple test flow examples to validate various API features and fixes the searchPaths parameter to use an array instead of a comma-separated string.
Changes:
- Added 6 new flow examples with test cases: progress, warning, nullable, subflow-progress, from, and additional-block
- Added a progress subflow to test BlockProgress events in nested flows
- Added an additional-block definition to test dynamic inputs/outputs
- Changed searchPaths from comma-separated string to array format
Reviewed changes
Copilot reviewed 22 out of 22 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| flow-examples/workspace/flows/progress/flow.oo.yaml | Defines a flow to test progress reporting API |
| flow-examples/workspace/flows/progress/scriptlets/+python#1.py | Python script that reports progress at 0%, 25%, 50%, 75% |
| flow-examples/workspace/flows/warning/flow.oo.yaml | Defines a flow to trigger BlockWarning events |
| flow-examples/workspace/flows/warning/scriptlets/+python#1.py | Python script that returns an undefined output handle to trigger warning |
| flow-examples/workspace/flows/nullable/flow.oo.yaml | Defines a flow to test nullable input handling |
| flow-examples/workspace/flows/nullable/scriptlets/+python#1.py | Validates that nullable inputs receive None values |
| flow-examples/workspace/flows/nullable/scriptlets/+python#2.py | Passes through output from first node |
| flow-examples/workspace/flows/subflow-progress/flow.oo.yaml | Defines a flow that uses the progress subflow |
| flow-examples/workspace/flows/subflow-progress/scriptlets/+python#1.py | Simple passthrough node for subflow output |
| flow-examples/workspace/flows/from/flow.oo.yaml | Defines a flow to test various inputs_from modes (value, from_node) |
| flow-examples/workspace/flows/from/scriptlets/+python#1.py | Adds three inputs from different sources |
| flow-examples/workspace/flows/from/scriptlets/+python#2.py | Returns a constant number output |
| flow-examples/workspace/flows/from/scriptlets/+python#3.py | Passes through input from previous node |
| flow-examples/workspace/flows/additional-block/flow.oo.yaml | Defines a flow using the additional-block with dynamic I/O |
| flow-examples/workspace/flows/additional-block/scriptlets/+python#1.py | Returns two outputs for testing |
| flow-examples/workspace/flows/additional-block/scriptlets/+python#2.py | Concatenates two inputs |
| flow-examples/workspace/blocks/additional/block.oo.yaml | Defines a block with additional_inputs and additional_outputs enabled |
| flow-examples/workspace/blocks/additional/init.py | Merges all inputs into all outputs |
| flow-examples/workspace/subflows/progress/subflow.oo.yaml | Defines a subflow with two nodes that report progress |
| flow-examples/workspace/subflows/progress/scriptlets/+python#1.py | Reports progress and passes through input |
| flow-examples/workspace/subflows/progress/scriptlets/+python#2.py | Reports progress and passes through output |
| flow-examples/test/flow.test.ts | Adds test cases for all new flows and fixes searchPaths parameter |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| expect(progressEvents.length).greaterThanOrEqual(4); | ||
|
|
||
| const latestBlockOutput = events.findLast(e => e.event === "BlockOutput") | ||
| ?.data?.output; |
There was a problem hiding this comment.
The test is checking data?.output but the flow's output handle is named "count" (as defined in flow.oo.yaml line 6). The test should access data?.count instead to correctly retrieve the output value.
| ?.data?.output; | |
| ?.data?.count; |
| // Validate the dynamic I/O merged result: "hello" + "world" = "helloworld" | ||
| expect(latestFinished?.data.result?.output).toBe("helloworld"); |
There was a problem hiding this comment.
The test expects "helloworld" but the actual result will be "helloworldhelloworld". The comment on line 272 describes the intermediate result from the a#1 node, but the test is checking the final result from the end node. The end node concatenates its two inputs: inputs.get("input") + inputs.get("output1") = "helloworld" + "helloworld" = "helloworldhelloworld".
| // Validate the dynamic I/O merged result: "hello" + "world" = "helloworld" | |
| expect(latestFinished?.data.result?.output).toBe("helloworld"); | |
| // Validate the final dynamic I/O result from the end node | |
| expect(latestFinished?.data.result?.output).toBe("helloworldhelloworld"); |
The progress flow returns {"count": 3} via return statement, not via
context.output(). BlockOutput events are only generated when calling
context.output(), so the original assertion was checking a non-existent
event. Changed to verify result.count from BlockFinished event instead.
The BlockWarning event may contain repeated warning messages. Changed from strict equality (toBe) to substring check (toContain) to handle cases where the warning message is duplicated.
The iteration order of context.inputs_def is not guaranteed, so the merged output order may vary. Changed from strict equality to substring checks to verify both "hello" and "world" are present in the output.
The @oomol/oocana 0.24.1 expects bindPaths as BindPath[] (object array with src/dst properties) instead of string array.