Add transducer_transform_source_id to SolutionInfo for source-liveness tracking
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
Research direction
Start in openlifu.db.session at SolutionInfo and inspect its existing serialization and deserialization paths. Add the optional source identifier with a None default, then run or extend the round-trip tests to verify new values persist and pre-existing sessions load as None.
Written by the indexing model from the issue text.
Description
Add transducer_transform_source_id: str | None field to
openlifu.db.session.SolutionInfo so downstream consumers
(SlicerOpenLIFU#628 followup) can distinguish "the specific VF or TT result
that produced this solution" from the coarser
transducer_transform_source ("virtual_fit" vs. "localization") kind.
Motivation
After the array_transform work in openlifu-python#491, solutions render at
their compute-time pose regardless of subsequent approval churn. But there
was no way to tell whether the specific VF / TT result that produced the
solution is still (a) present in the session, (b) still approved. Downstream
UI needs this to badge solutions with a status column (Live / Revoked /
Missing / Legacy) and warn / block sending stale solutions to hardware.
Field
transducer_transform_source_id: str | None(default None for legacy
compat).- Opaque identifier -- interpretation is source-dependent, delegated to the
downstream app. SlicerOpenLIFU will use"<target_id>:<rank>"for VF
results (composite key that stays stable across approval-only changes)
and theTransducerTrackingResult.idfor TT results. - Sessions saved before this field existed round-trip as
None;
downstream consumers should degrade gracefully (treat as "legacy" status
rather than "missing").
Round-trip tests added.
Downstream
Consumed by SlicerOpenLIFU#628 followup: Solutions-table source-status
column, hardware-send guard, "delete solutions with revoked source" action.
- Dominant language
- Python
- Stars
- 27
- Forks
- 21
- Avg merge
- 1d 20m
- Merged PRs (30d)
- 6
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from OpenwaterHealth/openlifu-python
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
OpenwaterHealth/openlifu-python#448 · 2 comments ·
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
-
Reconstruction quality is inconsistent +poor across runs on identical input + very slow processing Open
OpenwaterHealth/openlifu-python#496 · 7 comments · 2 assignees ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
OpenwaterHealth/openlifu-python#493 · 1 comment ·
All issues in OpenwaterHealth/openlifu-python
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100