feat(dc_bridge): add unmanaged-shipper mode and atomic config write - #454
Merged
Minipada merged 2 commits intoAug 31, 2026
Merged
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## jazzy #454 +/- ##
==========================================
+ Coverage 70.93% 71.02% +0.09%
==========================================
Files 119 120 +1
Lines 7402 7462 +60
==========================================
+ Hits 5250 5299 +49
- Misses 2152 2163 +11
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
`shipper.managed: false` lets an orchestrator own the Shipper's lifecycle (the split-deployment topology, #440): the Bridge still renders the config and connects over the shipper ingest protocol, but locates no binary, spawns no child, and installs no parent-death signal. Readiness already tracked the Shipper via a TCP probe rather than the supervisor, so it reports ready the same way in both modes with no change needed there. The rendered config is now always written atomically (write then rename, matching the Uploader intent queue's existing convention) via a new dc_bridge_core `atomic_write` helper, and its path is configurable via `shipper.config_path` so it can be placed on a volume shared with an unmanaged Shipper container. Closes #444 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VuumU1P7drY5cr54p3dw9D Signed-off-by: David Bensoussan <d.bensoussan@proton.me>
Add a "Deployment modes" section to doc/src/dc/destinations.md: a side-by-side comparison of managed vs. unmanaged supervision, and which one to pick — managed (default) for single-robot/simulation/local dev, unmanaged for a multi-container/orchestrator-managed deployment. Points to #440 for the larger split-deployment/fleet work this parameter is a building block for, without overclaiming it's already shipped. Also cross-references the new doc section from the shipper.managed comment in dc_bringup/params/dc_params.yaml. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VuumU1P7drY5cr54p3dw9D Signed-off-by: David Bensoussan <d.bensoussan@proton.me>
Minipada
force-pushed
the
feature/444-bridge-unmanaged-shipper-mode-and-atomic
branch
from
August 31, 2026 11:25
4c0250e to
a81c0b8
Compare
github-actions
Bot
deleted the
feature/444-bridge-unmanaged-shipper-mode-and-atomic
branch
August 31, 2026 12:07
8 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
shipper.managed(bool, defaulttrue): the Bridge's existing spawn/supervisebehavior stays the default and is unchanged.
shipper.managed: false(the split-deploymenttopology, Split deployment: Shipper and Uploader as their own containers, for fleet deployment #440) has the Bridge render the config and connect exactly as before, but locate
no binary, spawn no child, and install no parent-death signal — an orchestrator owns the
Shipper's lifecycle instead.
<path>.tmp, thenrename()) via anew
dc_bridge_core::write_file_atomicallyhelper, so a Shipper reading the file — its ownprocess in managed mode, an orchestrator-supervised one in unmanaged mode — can never observe
a partial write.
shipper.config_path(optional, defaults to the historic temp-file path) makes the configlocation configurable, so it can be placed on a volume shared with the Shipper
container/pod.
~/readyservice already tracked the Shipper via a TCP probe independent of thesupervisor, so readiness reports correctly in both modes with no logic change there.
Acceptance criteria (issue #444)
Test plan
prek run --all-files --skip build-docpasses (clang-format, ruff, REUSE, etc.)AtomicWritegtest cases todc_bridge/test/misc_test.cpp(write+rename, overwrite, failure on missing directory)colcon test) — this environment has no ROS/colcon workspace to build/test locally; relying on CIvectorby hand pointed atshipper.config_path, launch the Bridge withshipper.managed: false, confirm Records arriveCloses #444
🤖 Generated with Claude Code
https://claude.ai/code/session_01VuumU1P7drY5cr54p3dw9D