38 lines
1.6 KiB
Markdown
38 lines
1.6 KiB
Markdown
---
|
|
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.
|