added print, download as pdf. no puppeteer, we'll see

2026-09-22 22:06:06 +03:00
parent 122480cd46
commit 6f614270e7
37 changed files with 3955 additions and 473 deletions
@@ -0,0 +1,37 @@
+---
+name: sse-operation-map-fallback
+description: sse_broadcast_update's operation_map only maps created/updated/deleted; other action strings pass through unchanged to the frontend's `operation` field
+metadata:
+  type: project
+---
+
+`backend/scalesapp/sse.py`'s `sse_broadcast_update(object_name, action, data)` maps
+`action` through a small dict:
+
+```python
+operation_map = {
+    'created': 'insert',
+    'updated': 'update',
+    'deleted': 'delete'
+}
+...
+'operation': operation_map.get(action, action),
+```
+
+Any action string NOT in that dict (e.g. `'archived'`, `'voided'`, added for the
+vehicle finalize/void feature) is **not translated** — it arrives client-side in
+`message.operation` exactly as the backend passed it, verbatim.
+
+**Why:** confirmed by reading the actual source during Phase B of
+`.claude/plans/finalize-history-void.md` (finalize/history/void feature), rather
+than assuming the plan's own hedge ("mapped through operation_map, or handled as
+raw fallback — check which is simpler") was already resolved. It wasn't resolved
+in the plan text; the code settles it.
+
+**How to apply:** when adding a new `handleSSEUpdate` case in
+`frontend/src/contexts/NomenclatureContext.jsx` for a new backend action, do NOT
+assume the operation string will be renamed/normalized — check `operation_map` in
+`backend/scalesapp/sse.py` first, and if the action isn't in the map, write the
+frontend case using the exact same string the backend passes as `action`. Do not
+add entries to `operation_map` yourself for a frontend-only task — that's a
+backend change and out of scope unless explicitly asked.