Provide a way to spawn workflows that checks for topology issues
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
Start by reading the workflow Builder and Commands construction paths, then trace how spawning differs from running when CircularCollect or an unreachable terminate operation is encountered. Done means topology errors are detected when the workflow is spawned, while preserving a consistent representation between the builder and queued commands.
Written by the indexing model from the issue text.
Description
Currently it is possible to get a CircularCollect cancellation error when running a workflow if a user puts two collect operations in one cycle. This is only caught when a service is run, not when it gets spawned.
Another error that can happen when running a workflow is if the terminate operation cannot be reached from the workflow input.
Besides these two topological errors, all other mistakes or unsupported workflow constructions are caught by the compiler, making the need for a holistic workflow error check somewhat niche. It is also difficult due to the fact that the workflow is built by Commands, with each element put into a queue. The workflow Builder doesn't have a holistic view of what the user has constructed, making it difficult to scrutinize.
To implement this feature, we would probably need to change the Builder to internally keep track of the topology of what the user has built, and analyze this internal representation after the user has finished spawning the workflow. This has a risk of fragmenting the source of truth between the internal representation and the version that's queued up in the commands. Perhaps one way of solving this is to create a new World to initially spawn the workflow inside of, evaluate the workflow inside the self-contained world, and then use Commands to transfer the spawned workflow into the real world.
- Dominant language
- Rust
- Stars
- 75
- Forks
- 18
- Avg merge
- 12d 12h
- Merged PRs (30d)
- 3
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from open-rmf/crossflow
-
Diagram editor fails to build on Windows: build.rs can't find pnpm (pnpm.cmd)Possibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 4/5 3-5 days Newbie friendliness 52/100
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
-
Difficulty 5/5 Over a week Newbie friendliness 45/100
All issues in open-rmf/crossflow
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
storytold/photocraft#14822 ·
Maintainers usually reply within 1 day
-
bug css
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
dginev/latexml-oxide#853 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 2 days
-
[Bug] export_build_environment admits its output directory only after the export ran in the build computerPossibly taken @viniciusdsandrade claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day