open-rmf / open-rmf/crossflow

Create a live sanity checker

Open
#14 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
72
Forks
16
PR merge metrics
No merged PRs in 30d

Description

Before proceeding, is there an existing issue or discussion for this?
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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

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.

Assessment

Tech stack
rust
Domain
backend, testing-qa
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.