Object references in titles are not remapped when appending an HDF5 workspace

[StefanoPierini-Codra]

Object references in titles are not remapped when appending an HDF5 workspace

Summary

When an HDF5 workspace is loaded in append mode (i.e. into a session that already contains objects), the objects and groups read from the file are renumbered, but the short IDs embedded in their titles are not. Every generated title that references another object (fft(s001), average(gs001), µ(s001, s002), ...) therefore points to the wrong object, or to an object that belongs to a completely different workflow.

Steps to reproduce

1. Start DataLab with an empty signal panel.
2. Create two signals (they get s001, s002), rename their group to Imported sources (gs001).
3. Compute average on the group → new group gs002 titled average(gs001) containing s004 titled µ(s001, s002).
4. Compute fft on the first signal → s003 titled fft(s001).
5. Save the workspace to probe.h5.
6. Clear all panels, create one new signal (so the session is not empty).
7. Load probe.h5 with append (reset_all=False).

Actual result

BEFORE SAVE                          AFTER APPEND
gs001: 'Imported sources'            gs001: ''                    <- pre-existing object
    s001: cosine(...)                    s001: cosine(...)
    s002: cosine(...)                gs002: 'Imported sources'
    s003: 'fft(s001)'                    s002: cosine(...)
gs002: 'average(gs001)'                  s003: cosine(...)
    s004: 'µ(s001, s002)'                s004: 'fft(s001)'        <- should be fft(s002)
                                     gs003: 'average(gs001)'      <- should be average(gs002)
                                         s005: 'µ(s001, s002)'    <- should be µ(s002, s003)

Because s001 and gs001 now designate the pre-existing objects of the session, the titles silently describe a wrong lineage.

Expected result

All short IDs contained in the titles of imported items should be rewritten to the short IDs those items receive in the current session:

gs002: 'Imported sources'
    s002 / s003: cosine(...)
    s004: 'fft(s002)'
gs003: 'average(gs002)'
    s005: 'µ(s002, s003)'

Root cause

ObjectModel.add_object() performs the usual short-ID ↔ UUID swap using the current model mapping. But the titles read from the file carry the file's short IDs, which have no relation to the current numbering. In addition, group UUIDs stored in the file are lost: deserialize_from_hdf5() calls add_group(), which allocates a fresh UUID, so group references cannot be resolved either.

Relevant code:

• datalab/gui/panel/base.py → BaseDataPanel.deserialize_from_hdf5()
• datalab/objectmodel.py → ObjectModel.add_object(), replace_short_ids_by_uuids_in_titles(), replace_uuids_by_short_ids_in_titles()

Notes

A regression test exists on the feature/149-replace-object-short-names-by-their-title branch: datalab/tests/features/common/computed_title_regressions_app_test.py::test_h5_append_remaps_group_computed_title.

[StefanoPierini-Codra]

Impact assessment: display only, with one exception

Good news first: in the vast majority of cases this bug is cosmetic. The data, the metadata and the processing lineage are intact — only the short IDs printed inside the titles are stale.

Verified with a probe on the append scenario:

AFTER APPEND
  s001: uuid=7b9944b4...  'cosine(...)'    <- pre-existing object
  s002: uuid=fa55e914...  'cosine(...)'    <- imported source
  s003: uuid=88b9970d...  'fft(s001)'      <- title WRONG
  fft source_uuid : fa55e914...
  resolved source : s002 'cosine(...)'     <- lineage CORRECT
  recompute       : True | Signal was reprocessed.

Object UUIDs are persisted in HDF5 (they are stored as the __uuid metadata option, and metadata is serialized as a whole), and on append they are preserved rather than regenerated (datalab/gui/panel/base.py, deserialize_object). Since recompute_processing() resolves the source through source_uuid and not through the title, Recompute and Show source keep working on the right object.

So what is actually affected is limited to:

• the title shown in the tree and in the plot legend;
• the "long title" display mode, which substitutes short IDs with the source titles;
• ObjectModel.get_object_from_title(), used by macros / remote API / Web API, which may resolve to the wrong object;
• the imported deleted_source_refs registry, still aligned with the file numbering.

The generic HDF5 import (HDF5 browser) is not affected at all: objects are rebuilt from scratch, titles come from the dataset path and metadata is reset, so no reference exists to be remapped.

The one exception: importing the same workspace twice

AFTER DOUBLE APPEND
  s001: 'cosine(...)'  uuid=57cda19d  source=None
  s002: 'fft(s001)'    uuid=5f1c1ad4  source=57cda19d -> s001
  s003: 'cosine(...)'  uuid=6a210c95  source=None        <- uuid regenerated
  s004: 'fft(s001)'    uuid=d97fdc20  source=57cda19d -> s001   <- should be s003

On the second import the UUIDs collide with the ones already present, so new UUIDs are assigned — but source_uuid inside __processing_parameters is not remapped and still points at the first copy. Consequences:

• s004 depends on s001 instead of its own sibling s003; recompute only appears to work because the two copies hold identical data;
• editing s003 is ignored by s004;
• deleting the first batch breaks recompute of the second one ("Source object no longer exists");
• Show source highlights the wrong object.

This is the same underlying gap — no reference remapping on import — but on a second channel: UUIDs in metadata rather than short IDs in titles. Both should ideally be handled by the same fix.