Summary
Reopening the Interactive Labeler on a layer that already has saved labels can show an empty label set. The client calls GetInteractiveLabels and the response contains the labels, but they are never applied to labeler state.
Filed separately from #101 because the failure mode and impact differ: #101 describes labels appearing progressively as you scroll, whereas here no labels ever appear, and there is an unguarded path that destroys the saved set. See my comment on #101 for the shared background — happy to have this merged in if maintainers prefer.
Environment
- haste-dev.aiforgood.ai, 2026-08-06/07
- Building-workflow layer, 112,687 Overture footprints
- DINOv2 ViT-B/14 embedding, model
3706
- 1,311 saved interactive labels (649 Damaged / 662 NotDamaged)
Steps to reproduce
- Label a large number of buildings in the Interactive Labeler and click Save labels.
- Confirm they persisted:
GET /api/haste/GetInteractiveLabels?projectId=<PID>&modelId=<MID> → returns all labels, correctly scoped to project/model/imageLayer, each with an updatedAt timestamp.
- Reload the labeler.
Expected
The saved labels are restored and the session can be resumed.
Actual
The panel shows Intact: 0 / Damaged: 0 / Cloudy: 0 and 0 labeled · 0 predicted in viewport. Panning and zooming does not recover them.
The network trace confirms the page does request GetInteractiveLabels and the endpoint does return all 1,311 labels — the response is simply not applied.
Two consequences
1. The session cannot be resumed. In the empty state, Save labels and Predict all buildings are both disabled. Only Clear labels is enabled.
2. Data loss. If the user labels even a few buildings to get started again, Save labels re-enables and overwrites the complete saved set with the partial one — no warning, no merge. I reproduced this: saving at that point reduced the server-side set from 1,311 labels to 552.
Practical effect: the browser session is the working state. A 14-round analysis only survived because the tab was never reloaded.
Suggested fix
- Apply the
GetInteractiveLabels response to labeler state on init.
- Until then, as a cheap guard: disable Save labels (or warn) whenever the server reports more labels than the client currently holds.
Notes on recovery
Recovery is possible but painful. I restored all 1,311 labels exactly by replaying them from a local GetInteractiveLabels backup and iterating a save/diff loop until server state matched the target. The re-run prediction then reproduced the original result to the building (647 damaged; 569 main burn / 45 secondary burn / 33 elsewhere). Happy to share the script if useful.
Summary
Reopening the Interactive Labeler on a layer that already has saved labels can show an empty label set. The client calls
GetInteractiveLabelsand the response contains the labels, but they are never applied to labeler state.Filed separately from #101 because the failure mode and impact differ: #101 describes labels appearing progressively as you scroll, whereas here no labels ever appear, and there is an unguarded path that destroys the saved set. See my comment on #101 for the shared background — happy to have this merged in if maintainers prefer.
Environment
3706Steps to reproduce
GET /api/haste/GetInteractiveLabels?projectId=<PID>&modelId=<MID>→ returns all labels, correctly scoped to project/model/imageLayer, each with anupdatedAttimestamp.Expected
The saved labels are restored and the session can be resumed.
Actual
The panel shows
Intact: 0 / Damaged: 0 / Cloudy: 0and0 labeled · 0 predicted in viewport. Panning and zooming does not recover them.The network trace confirms the page does request
GetInteractiveLabelsand the endpoint does return all 1,311 labels — the response is simply not applied.Two consequences
1. The session cannot be resumed. In the empty state, Save labels and Predict all buildings are both disabled. Only Clear labels is enabled.
2. Data loss. If the user labels even a few buildings to get started again, Save labels re-enables and overwrites the complete saved set with the partial one — no warning, no merge. I reproduced this: saving at that point reduced the server-side set from 1,311 labels to 552.
Practical effect: the browser session is the working state. A 14-round analysis only survived because the tab was never reloaded.
Suggested fix
GetInteractiveLabelsresponse to labeler state on init.Notes on recovery
Recovery is possible but painful. I restored all 1,311 labels exactly by replaying them from a local
GetInteractiveLabelsbackup and iterating a save/diff loop until server state matched the target. The re-run prediction then reproduced the original result to the building (647 damaged; 569 main burn / 45 secondary burn / 33 elsewhere). Happy to share the script if useful.