mirror of
https://github.com/MBombeck/HealthLog.git
synced 2026-11-08 20:42:43 +00:00
Marc-André Bombeck
9c4235b66d
Three of the restore's lookups resolve a key against a seeded catalogue: cycle symptoms, illness symptoms, mood factors. Each threw on a key it could not resolve, inside the one transaction that wipes and rebuilds the account. So a single renamed symptom rolled everything back and answered 500. No measurements, no doses, no notes, nothing. A year-old backup read by a newer instance is the ordinary case for a backup, and the catalogue drifts between those two dates by design. The unresolvable link is dropped and named now. What it costs is one association between a row and a symptom; the day-log, the mood entry, the flow, the temperature and the encrypted note all come back. The count and the exact keys ride the response, the audit row and the wide event, and the admin surface shows them in a panel that stays put instead of a toast that leaves. A quiet drop would be the older failure of this same seam wearing a success message. A dangling `cycleId` or a dose recorded against a medication the file never carried still throws. Those name rows the file was supposed to hold, so a missing one means the file contradicts itself. A catalogue key names a row the instance owns, which is why it gets the other answer. `IllnessSymptom` carries no owner column at all, so a key that will not resolve there can only ever be drift; the file was never able to supply it. The restore does not mint the missing catalogue row back. That would preserve the link at the price of reference data colliding with whatever the next migration seeds under that key, and a label nothing can translate.