fix(chat): tolerate legacy command metadata that exceeds the money decimal scale - #131
Conversation
76050e1 to
f2f1fb7
Compare
damianrzepka
left a comment
damianrzepka
left a comment
There was a problem hiding this comment.
Review: fixes the reported bug correctly. Legacy rain-split rows with numeric(38,20) amounts now canonicalize on read and pass ChatMessageSchema; regression test added and passing (ran the full chat.service.int.test.ts suite locally - 138/138). Lint clean on the touched files. Traced getGlobalMessages end to end (viewer id from session, query filters intact, read-only, output matches contract) - same code path also covers getRoomMessages and listAdminRoomMessages, no other reader of chatMessage.metadata in the repo.
One inline note on chat.service.ts:299 - the canonicalization also silently reformats amounts that were never invalid (trims trailing zeros unconditionally), not just the legacy over-precision rows. Doesn't break the contract or lose value, so not blocking, but worth tightening to only touch the actually-broken rows.
GO.
…cimal scale A rain command message persisted by the retired SQL rain split stored its share as numeric(38,20), so metadata.amount / metadata.perRecipient carry more fraction digits than MoneyAmountSchema now allows. getGlobalMessages validates the whole batch against ChatMessageSchema, so one such historical row returned a 500 for every viewer loading global chat. Canonicalize the command metadata money fields on read (trim trailing zeros, truncate to MONEY_SCALE) in toSystemMessage.
f2f1fb7 to
7140561
Compare
4 participants
What
toSystemMessagenow canonicalizes the money strings in chat command metadata (amount,perRecipient) when a message is read: trailing zeros trimmed, fraction truncated toMONEY_SCALE(18).Why
A
raincommand message persisted by the retired SQL rain split stored its share asnumeric(38,20), sometadata.amount/metadata.perRecipientcarry more fraction digits thanMoneyAmountSchemanow allows.getGlobalMessagesvalidates the whole batch againstChatMessageSchema, so a single such historical row made the endpoint return a 500 for every viewer loading global chat. Observed on a downstream operator's dev environment (5 legacy rows).Acceptance
getGlobalMessagesreturns a legacy rain message whose metadata amounts have 20 decimal places, canonicalized to a contract-valid form, and the row parses againstChatMessageSchema.chat.service.int.test.ts.check:types,oxlint,oxfmtpass; fulltest:integrationgreen (1228 passing).