1.6 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| sse-operation-map-fallback | sse_broadcast_update's operation_map only maps created/updated/deleted; other action strings pass through unchanged to the frontend's `operation` field |
|
backend/scalesapp/sse.py's sse_broadcast_update(object_name, action, data) maps
action through a small dict:
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.