Create a live sanity checker
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- rust
- Domain
- backend, testing-qa
Research direction
Start by reviewing the bevy_impulse workflow implementation and the UnhandledErrors path, then inspect the library's existing tests. Define how periodic audits should check ongoing and finished sessions, how affected workflows are cancelled and logged, and how users configure the audit frequency; done means the tool is applied across the tests and can be configured for deployments.
Written by the indexing model from the issue text.
Description
Before proceeding, is there an existing issue or discussion for this?
- I have done a search for similar issues and discussions.
Description
bevy_impulse is completely event-driven which is good for efficiency, but introduces a non-zero risk that a subtle uncaught bug somewhere in the implementation (perhaps an extremely rare race condition) could cause execution of a workflow to get permanently stuck.
While we strive to not have any bugs at all in the implementation, the reality of the risk should not be ignored. We should implement a system that can periodically audit the ongoing workflows to verify that all activities are running as expected and that no workflows have come to an unexplained stop. If anything is found to be out of order, the affected workflow should be cancelled and the situation should be logged in UnhandledErrors in as much detail as possible.
Things to examine:
- Can all ongoing scoped sessions reach their terminal nodes?
- Are all buffers of finished session cleared out?
- Are all inputs of finished sessions cleared out?
- Are all finished impulses despawned?
This tool should be applied to every test in the library. We should also make it something that users can configure to run periodically to prevent problematic halts in deployments, although it should not be run very frequently.
- 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