fix(dc_bridge): carry Measurement custom keys onto File metadata Records - #420
Merged
Minipada merged 1 commit intoAug 21, 2026
Merged
Conversation
A Measurement's `custom_key_str_list` keys reached its Records but not the Uploader's `file_status`/`group_complete` rows, which were built from a fixed field set — so the Records and the Files of one Measurement ended up labelled differently, with nothing logged. A Record now names its custom keys in a `custom_keys` field, which is the only way the Uploader can tell `site` from a measured field. Those keys are appended to every File metadata row, including retention's shed rows. Dropped rather than written, in both cases from every row kind so a File and its group marker can't disagree: - a key naming a field the Uploader computes itself (`storage_type`, `size`, …) — the Uploader's value is kept and the Bridge warns; - `name`, `id` and `robot_name`, which the rows already carry as `group_name`, `robot_id` and `robot_name` — re-emitting `id` would put a robot identifier in whatever an `id` column happens to be. A Measurement with no custom keys produces the rows it did before. Closes #419 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015oGKFjBD4WKxMHYv3iKXBo Signed-off-by: David Bensoussan <d.bensoussan@proton.me>
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## jazzy #420 +/- ##
==========================================
+ Coverage 70.80% 71.12% +0.33%
==========================================
Files 114 114
Lines 7440 7478 +38
==========================================
+ Hits 5267 5318 +51
+ Misses 2173 2160 -13
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:
|
github-actions
Bot
deleted the
feature/419-dc-bridge-measurement-custom-keys-are-dr
branch
August 21, 2026 15:39
6 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.
Closes #419
Problem
A Measurement's
custom_key_str_listkeys are appended to the JSON of its Records, so theyreach a PostgreSQL Destination as columns. The Uploader built its
file_statusandgroup_completerows from a fixed field set, so the same keys were silently dropped onthe File side: configure
custom_key_str_list: ["site"]on a camera Measurement andsiteappeared in
dc_recordsand never indc_files, with nothing logged.What changed
The Record names its custom keys.
Measurement::addCustomKeys()now writes acustom_keysarray alongside the values it already inlines. Without it the Uploader has noway to tell
sitefrom a measured field — every top-level key of a Record looks the samefrom the Bridge. A Measurement with no custom keys writes nothing, exactly as before.
The Uploader carries them onto every File metadata row.
parse_file_group()reads thedeclaration and its values into
FileGroup::custom_keys;status.cppappends them last,to
uploaded/missing/deletedrows, retention'sshedrows, and thegroup_completemarker, so a File group and its members are labelled the same way.
Collisions
Two kinds of key are dropped instead of written — in both cases from every row kind, not
just the ones that happen to carry the field, so a File and its group marker can never
disagree about what a name means:
storage_type,size,remote_path, …)ProcessSummary::dropped_custom_keysand the Bridge logs a warningname,id,robot_namegroup_name,robot_idandrobot_nameThe second row matters for the demos, which all configure
custom_key_str_list: ["robot_name", "id"]. Emitting a bareidwould write a robotidentifier into whatever an
idcolumn happens to be — a serial primary key, for instance.Scope
The columns still have to exist in the Destination. The PostgreSQL sink maps JSON keys onto
existing columns 1:1, so this makes the keys available on the File path; it does not
create schema.
Group-merged Records are unaffected: the Group node namespaces its members' fields under
their
group_key, so those keys are no longer the Measurement's own labelling and theparse is deliberately top-level only.
Tests
dc_bridge/test/uploader_test.cpp(4 new, asserting on the emitted rows):file_statusrow (uploaded + deleted) and thegroup_completemarkerrobot_name/idare not repeated and not reporteddc_measurements/test/test_measurement_dummy.cpp(2 new): a Record with custom keys carriesthe value and the declaration; without them the Record is untouched.
colcon test: dc_bridge 169/169, dc_measurements 295/295.Docs
doc/src/dc/measurements.md—custom_key_str_list's row, plus a "Custom keys on Files"section covering the collision rule and the
ALTER TABLEcaveat.🤖 Generated with Claude Code
https://claude.ai/code/session_015oGKFjBD4WKxMHYv3iKXBo