osobhandClaude Fable 5
ad6405663f
CI / Format Check (push) Failing after 7s
CI / Build (ubuntu-latest) (push) Failing after 7s
CI / Clippy Check (push) Failing after 8s
Documentation / Build API Documentation (push) Failing after 7s
Documentation / Build User Guide (push) Successful in 8s
CI / Build (macos-latest) (push) Failing after 8s
CI / Test (macos-latest) (push) Has been skipped
CI / Test (ubuntu-latest) (push) Has been skipped
CI / Python Bindings (maturin) (macos-latest) (push) Has been skipped
CI / Python Bindings (maturin) (ubuntu-latest) (push) Has been skipped
CI / WASM Build + Size Check (push) Has been skipped
CI / Distributed Training Tests (push) Has been skipped
Performance Benchmarks / Run Benchmarks (push) Successful in 26s
CI / Build CPU-Only (Explicit) (push) Failing after 1m17s
CI / CI Success (push) Failing after 0s
The new lifecycle tests caught that the batch-optimizer worker crashed at spawn: DynamicBatchingConfig derived Default (all zeros), and tokio's interval() panics on a zero period. Default is now a usable config (batch 32 in [1,128], step 4, 1ms latency target, 100-sample window, 1s optimization interval, AIMD adaptation). New regression tests in AdaptiveProcessor, EdgeComputingManager, and MonitoringSystem assert that all workers are still alive shortly after start() (catches workers dying at startup) and that stop() completes via the graceful control-channel path, not the 5s abort backstop (catches shutdown hangs). cargo test -p rtx-streaming: 58 lib + 8 integration + 6 aux, all green. Co-Authored-By: Claude Fable 5 <[email protected]>