Session can contain stale references to photoscans

[peterhollender]

The Session class, when loaded, may contain references to photoscans that are no longer in the database. If calling software attempts to retrieve these, file not found errors will occur. We should verify the validity of transducer tracking results in the session and sanitize on load.

[vaishnavidesai09]

Reproduction attempt:

• Commit/branch tested: main (886d683)
• Environment: Windows 10, Python 3.14.2
• Steps taken:
  1. Inspected src/openlifu/db/session.py
  2. Traced TransducerTrackingResult loading at lines 147–151
• Outcome: Confirmed bug in code — photoscan_id is loaded directly from stored data at line 147 with no check that the referenced photoscan exists in the database. No sanitization on load is present.
• Runtime reproduction blocked by missing kwave dependency, but the structural issue is confirmed by code inspection.

(I don't have write access — could a maintainer apply needs-triage:reproduced / needs-info?)

[dblizinski]

@vaishnavidesai09 - nice catch. A dangling reference like this is difficult to trigger during runtime since you would need to delete a photoscan and then load a session that still points to it. Therefore, inspecting it manually is the best approach. You identified it accurately: TransducerTrackingResult directly loads photoscan_id from the saved data in session.py (lines 147–151) without verifying if the referenced photoscan still exists.

Marking this reproduced. The solution isn't clear yet and depends on a design decision: should loading a missing photoscan_id trigger an error or a warning, or be permitted as a lazy reference that resolves later? I am marking this for our Open-LIFU maintainer to comment on the intended behavior before anyone starts coding. I'll update here once we make a decision.

[peterhollender]

Same issue here as #468. Came across this bug when cleaning up the sample database, and have a fix in the works. I think there will be a larger reckoning and refactoring of the data model in the coming months (moving to a proper relational database, and taking everything we've learned about the data structures and trying to streamline what is referenced where and how), so the triage fix of kicking out a warning and ignoring stale references will tide us over until then, as it will keep the applications that use this code from having unexpected exceptions.