Skip to content

[CHORE] (cu29_runtime) improve error handling#708

Merged
gbin merged 4 commits into
masterfrom
yang/fix/cu29_runtime_error_handling
Jan 22, 2026
Merged

[CHORE] (cu29_runtime) improve error handling#708
gbin merged 4 commits into
masterfrom
yang/fix/cu29_runtime_error_handling

Conversation

@makeecat

Copy link
Copy Markdown
Collaborator

No description provided.

@makeecat makeecat self-assigned this Jan 22, 2026

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7c4395f658

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread core/cu29_runtime/src/cuasynctask.rs Outdated
Comment on lines +132 to +136
// clone the last finished output (if any) as the visible result for this polling round
let buffered_output = self.output.lock().unwrap();
let buffered_output = self
.output
.lock()
.map_err(|_| CuError::from("Async task output mutex poisoned"))?;

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Reset async state when output lock is poisoned

If the output mutex is poisoned, this ? returns early with an error after state.processing was already set to true earlier in process. That leaves the async state permanently in “processing” without any background task running, so every later poll will return Ok(()) and never reschedule work. This only happens when the output mutex is poisoned (e.g., a panic in a previous background run), but in that case the task will deadlock instead of surfacing the error. Consider clearing processing and recording last_error when this lock fails.

Useful? React with 👍 / 👎.

@gbin gbin merged commit cb254c1 into master Jan 22, 2026
23 checks passed
@gbin gbin deleted the yang/fix/cu29_runtime_error_handling branch January 22, 2026 22:46
gbin pushed a commit that referenced this pull request Jan 22, 2026
* (cu29_runtime) improve error handling

* cleared the async processing state and recorded the error when the output mutex is poisoned in CuAsyncTask::process

* fmt
gbin added a commit that referenced this pull request Jan 23, 2026
* Iceorix2 ported as a bridge.

* ronfmt lint

* simplify

* [CHORE] Removed unused `cu29::prelude::*` imports causing warnings in generated workspace templates: (#711)

- `templates/cu_full/components/bridges/cu_example_shared_bridge/src/messages.rs`
- `templates/cu_full/apps/cu_example_app/src/messages.rs`

You can regenerate the workspace and rerun `cargo build` to confirm the warnings are gone.

* Resolve cu29_export merge conflict

* (cu29_helpers) improve error handling (#703)

* (cu29_value) improve error handling (#702)

* (cu29_log) improve error handling (#705)

* (cu29_soa_derive) improve error handling (#706)

* Upgraded the glam dependency to 0.31 in the two crates that declare it, and verified both dependent crates still check cleanly. (#713)

Changes:
- Updated glam version in `components/libs/cu_transform/Cargo.toml`.
- Updated glam version in `components/payloads/cu_spatial_payloads/Cargo.toml`.

Checks run:
- `cargo +stable check -p cu-transform -p cu-spatial-payloads`

Next steps (optional):
1. Run `cargo +stable check --workspace` if you want broader coverage.
2. Run `cargo +stable nextest run -p cu-transform -p cu-spatial-payloads` if you want tests as well.

* Updated nix dependency versions to `0.31` in the two crates that directly use it and ran cargo check on those crates. (#714)

Changes:
- `components/sources/cu_v4l/Cargo.toml`
- `examples/cu_msp_bridge_loopback/Cargo.toml`

Checks run:
- `cargo +stable check -p cu-v4l -p cu-msp-bridge-loopback`

If you want, I can also run the broader CI-aligned checks (`just std-ci`) or `cargo +stable nextest run --workspace --all-targets`.

* [CHORE] update cudarc deps to 0.19 (#715)

* (cu29_log_derive) improve error handling (#707)

* [CHORE] (cu29_runtime) improve error handling (#708)

* (cu29_runtime) improve error handling

* cleared the async processing state and recorded the error when the output mutex is poisoned in CuAsyncTask::process

* fmt

* [CHORE] (cu29_unifiedlog) improve error handling (#704)

* (cu29_unifiedlog) improve error handling

* simplify

---------

Co-authored-by: Yang Zhou <yangzhou.info@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants