You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix LSN encoding in responses and handling in JS (#2446)
Follow-up to #2442
Randomizing the WAL start point in tests has highlighted problems with
how we handle LSNs in Javascript.
Javascript can only do max 53-bit number representations, after which it
will start doing nonsense without telling you (gotta love it), but LSNs
span the entire 64-bit range.
In order to fix that, we encode the `lsn` and `global_last_seen_lsn` as
strings in the responses rather than integers, so that Javascript can
either compare them as strings or convert them to `BigInt`s, both would
yield valid comparisons.
JSON itself does not really care, and other languages are able to parse
large integers correctly, but for the sake of portability in the current
landscape I think it's better to keep it encoded only once and as a
string, rather than e.g. twice as `lsn` and `lsn_str` - feels like
overkill.
I've kept the `op_position` as a number, because it would be really odd
for a transaction to have `> 2^32` operations in it - maybe if the need
arises or if we want consistency between `lsn` and `op_position` I can
convert those as well.
For the `MultiShapeStream`, I decided to parse the LSNs into `BigInt`s
even though we don't really do any calculations with them and we could
just compare them as strings, but I felt like this is more explicit,
more easily understood while reading, and less error prone in the
future, and the performance cost given that this is a primarily
network-heavy utility I think is negligible, but I'm happy to change
that if anyone feels strongly about this.
0 commit comments