fix(daemon): bind dynamic-node listener once, not per reconnect (#1999) (#2000)
Daemon::run()calledset_up_event_streamon every reconnect, which bound the dynamic-node listener (local_listen_port) each time. The listener task from the previous connection kept running and holding the port, so the rebind hitAddrInUseandspawn_listener_loopreturnedOk(None)– the daemon silently continued without a dynamic-node listener after its first reconnect, and leaked the old listener task.Bind the listener once, before the reconnect loop, for the daemon’s lifetime. The receiver is held in
run()(so the channel stays open across reconnect gaps) and a clone is streamed into each iteration’s event stream.set_up_event_streamnow takes the receiver instead of a port and no longer binds.The one-shot
run_dataflowpath (which binds its own listener once and has no reconnect loop) is unchanged.Verified locally: after forcing a coordinator reconnect, the daemon re-registers and logs zero “listen port already in use” warnings (the leak symptom); previously the rebind logged it on every reconnect.
Co-authored-by: Claude Opus 4.8 (1M context) noreply@anthropic.com
版权所有:中国计算机学会技术支持:开源发展技术委员会
京ICP备13000930号-9
京公网安备 11010802047560号
English | 简体中文
Website | Python API | Rust API | Guide | Discord
Dora
Agentic Dataflow-Oriented Robotic Architecture – a 100% Rust framework for building real-time robotics and AI applications.
User Guide | 用户指南 (中文)
Table of Contents
Features
Performance
Developer experience
dora runfor local dev,dora up/startfor distributed prod, plus build, logs, monitoring, record/replay all from one toolProduction readiness
dora node add/remove/connect/disconnect) without restarting--rtflag for mlockall + SCHED_FIFO; per-nodecpu_affinitypinning in YAML; comprehensive tuning guide for memory locking, kernel params, and container deploymentDebugging and observability
.drecfiles, replay offline at any speed with node substitution for regression testingtopic echoto print live data,topic hzTUI for frequency analysis,topic infofor schema and bandwidthdora topTUI showing per-node CPU, memory, queue depth, network I/O, restart count, and health status across all machines;--onceflag for scriptable JSON snapshotstrace listandtrace viewfor viewing coordinator spans without external infrastructureEcosystem
Installation
From crates.io (recommended)
From source
Platform installers
macOS / Linux:
Windows:
Build features
tracingmetricspythonredb-backendQuick Start
1. Run a Python dataflow
This runs a sender -> transformer -> receiver pipeline. Here’s what the Python node code looks like:
See the Python Getting Started Guide for a full tutorial, or the Python API Reference for complete API docs.
2. Run a Rust dataflow
3. Distributed mode (ad-hoc)
4. Managed cluster
See the Distributed Deployment Guide for cluster.yml configuration, label scheduling, systemd services, rolling upgrades, and operational runbooks.
CLI Commands
Lifecycle
dora run <PATH>dora updora downdora build <PATH>dora start <PATH>dora stop <ID>dora restart <ID>Monitoring
dora listps)dora cleandora logs <ID> [--node <NAME>]dora topdora inspect topdora topic listdora topic hz <TOPIC>dora topic echo <TOPIC>dora topic info <TOPIC>dora node listdora node info <NODE>dora node add --from-yaml <FILE>dora node remove <NODE>dora node connect <SRC> <DST>dora node disconnect <SRC> <DST>dora node restart <NODE>dora node stop <NODE>dora topic pub <TOPIC> <DATA>dora param list <NODE>dora param get <NODE> <KEY>dora param set <NODE> <KEY> <VALUE>dora param delete <NODE> <KEY>dora trace listdora trace view <ID>dora record <PATH>.drecfiledora replay <FILE>.drecfileCluster management
dora cluster up <PATH>dora cluster statusdora cluster downdora cluster install <PATH>dora cluster uninstall <PATH>dora cluster upgrade <PATH>dora cluster restart <NAME>Setup and utilities
dora doctordora statuscheck)dora newdora graph <PATH>dora expand <PATH>dora validate <PATH>dora systemdora completion <SHELL>dora self updateFor full CLI documentation, see docs/cli.md. For distributed deployment, see docs/distributed-deployment.md.
Dataflow Configuration
Dataflows are defined in YAML. Each node declares its binary/script, inputs, and outputs:
Built-in timer nodes:
dora/timer/millis/<N>anddora/timer/hz/<N>.Input format:
<node-id>/<output-name>to subscribe to another node’s output. Long form supportsqueue_size,queue_policy(drop_oldestorbackpressure), andinput_timeout. See the YAML Specification for details.Type annotations: Optionally annotate ports with type URNs for static and runtime validation. See the Type Annotations Guide for the full type library.
Modules: Extract reusable sub-graphs into separate files with
module:instead ofpath:. See the Modules Guide for details.Architecture
Key components
Workspace layout
Language Support
dora-node-apidora-operator-apipip install dora-rsdora-node-api-cdora-operator-api-cdora-node-api-cxxdora-operator-api-cxxdora-ros2-bridgePlatform support
Gate meanings (#1716):
mainruns these tests; merge is blocked on failure..github/workflows/nightly.yml) runs these. A failure auto-files anightly-regressionissue but does NOT block PRs.dora new --lang rust/pythontemplate tests run in nightly across all three platforms; C/C++ variants run in nightly on Linux only. Developers who need cross-platform verification before merge can runmake qa-test/make qa-examples/make qa-nightlylocally. Seedocs/testing-matrix.mdfor the full rationale.Examples
Core language examples
Composition
dora validateCommunication patterns
request_idcorrelationSee docs/patterns.md for the full guide.
Dynamic topology
Advanced patterns
Logging
dora/logsPerformance
ROS2 integration
MAVLink 2 integration
--uv)cargo run --example mavlink2-bridge-cxx)Development
Rust edition 2024; MSRV and default workspace package metadata are tracked in
[workspace.package]of the rootCargo.toml. Most crates inherit the workspace version viaversion.workspace = true; a handful (e.g.apis/rust/operator/types, theexamples/error-propagation/*samples) pin their own version independently.Build
Test
Lint and format
Run examples
Quality assurance
Dora ships with a three-tier QA system designed for AI-authored code. Everything runs locally first; CI mirrors the same scripts.
On Ubuntu, install
ripgrepseparately and installtypos-cliwith Cargo:Gates in place:
cargo-audit+cargo-denyfor CVEs, license policy, dependency bans.unwrap()/.expect(in production code; can only go down (.unwrap-budget)cargo-llvm-covwith diff-coverage gate (70% on PR-touched lines)cargo-mutantsagainst critical crates (library crates at package scope, binary crates withtest_workspace = true)propteston wire-protocol types; catches edge cases unit tests missdora-core::metadata)cargo-semver-checksagainst the last git tagscripts/qa/adversarial.shruns a different model on your diff to catch single-model blind spots (local today; CI pending API secret)Reference docs:
Contributing
We welcome contributors of all experience levels. See the contributing guide to get started.
For non-trivial work, discuss the approach in a GitHub issue, discussion, or Discord thread before implementing it. Before opening or updating a PR, run the QA level appropriate for the change and include the validation you ran in the PR description. The Contributor QA Cheat Sheet is the fastest day-to-day reference; the stricter per-change policy lives in docs/agentic-qa-policy.md.
Communication
Agentic Engineering
This repository is built with agentic engineering. AI agents collaborate on day-to-day work – code generation, reviews, refactoring, testing, drafting PR comments, triaging nightly regressions – while maintainers set direction, review judgments, and authorize what ships. The two roles compound: AI agents move fast on mechanical work; humans catch the things that matter.
License
Apache-2.0. See NOTICE.md for details.