Repository navigation
fix(chat): keep the token quarks and receiver on cash messages - #1806
Merged
Merged
Conversation
Incoming cash messages mapped nativeAmount, currency and mint from CryptoPaymentAmount but dropped its quarks, the on-chain token amount of the mint. Send Back needs it to return the exact amount received. MessageContent.Cash gains tokenQuarks: Long?, parsed from the proto and persisted in MessageContentSerialized.Cash. It is nullable and defaulted because rows stored before this have no value; callers must treat null as unknown, not zero. The existing quarks field (the fiat value) is unchanged, so no Room migration is needed. The reverse proto mapping writes tokenQuarks when known and falls back to the fiat quarks as before.
The cash receiver was parsed from the proto but never stored, so it was lost on the DB round trip. That matters in groups, where it names who was paid. MessageContentSerialized.Cash gains a nullable base58 receiver, encoded like intentId, so rows stored before this still decode to null. The reverse proto mapping now sets the receiver when known. The KDoc on MessageContent.Cash.receiver now matches the proto: always set in a group, set on new DM messages and unset on older ones.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Incoming cash messages lose two fields from
CashContent: the token amount, and, once stored, the receiver.Token quarks.
ProtobufToLocalmapsnativeAmount,currencyandmintfromCryptoPaymentAmountbut dropsquarks, the amount of the mint that actually moved. iOS keeps it (ExchangedFiat.onChainAmount). Send Back needs it to return exactly what was received.MessageContent.CashgainstokenQuarks: Long?, parsed from the proto and stored inMessageContentSerialized.Cash.Receiver.
receiveris parsed intoMessageContent.CashbutMessageContentSerialized.Cashhas no field for it, so it is gone after the DB round trip. In a group it names who was paid. It is now stored as base58, the same way asintentId. The KDoc onreceiversaid "null for DM cash". The proto says it is always set in a group and set on newer DM messages, so the KDoc now says that.Both new serialized fields are nullable with defaults, so rows stored before this decode to null. Callers should read null as unknown, not zero. Old rows pick the values up the next time the message is fetched. The existing serialized
quarksfield holds the fiat value and is unchanged. Cash content is stored as JSON, so there is no Room migration.asContent()now writestokenQuarksto the proto'squarkswhen known, falling back to the fiat quarks as before, and setsreceiverwhen known. Nothing sends cash content from the client today, so this has no effect yet.Tests cover the proto mapping in both directions, the converter round trip, a legacy cash row without the new fields decoding to null, and the entity mapper with and without values.