parseHoldersCount used parseInt, which reads the leading digits and drops the rest: "1,000" became 1, "0x10" 0, "1e3" 1. That is a reported low count, so the transaction history and the send-screen token selector would hide the token, the outcome #230 was fixed to prevent. It now takes only a whole number of zero or more, or a string of digits alone, and returns null (unknown) for anything else. The comment says exactly that.
The balance list's holders !== null && is dropped, not made load-bearing: null >= 1000 is already false. The existing test that an unknown count does not admit an unvouched token covers it, and the comment there now says why.
README.md and docs/README.md now say what an unknown count is and how each filter treats it: the history and the send selector keep the token, and the balance list admits it only if it is on the bundled list or tracked. They also say the token screen leaves out its "Holders:" row when the count is unknown, rather than showing 0. README.md lists src/shared/holders.js in the source tree.
Judgement call: a negative count (-5 or "-5") is now unknown too. parseInt used to keep it, as a low count. A test pins this.
Also touched: the comment above holders in src/shared/transactions.js now says "no readable count", because null now covers a malformed count as well.
Model: opus-5-5
Closes https://git.eeqj.de/sneak/AutistMask/issues/251.
`parseHoldersCount` used `parseInt`, which reads the leading digits and drops the rest: `"1,000"` became 1, `"0x10"` 0, `"1e3"` 1. That is a reported low count, so the transaction history and the send-screen token selector would hide the token, the outcome https://git.eeqj.de/sneak/AutistMask/issues/230 was fixed to prevent. It now takes only a whole number of zero or more, or a string of digits alone, and returns `null` (unknown) for anything else. The comment says exactly that.
The balance list's `holders !== null &&` is dropped, not made load-bearing: `null >= 1000` is already false. The existing test that an unknown count does not admit an unvouched token covers it, and the comment there now says why.
`README.md` and `docs/README.md` now say what an unknown count is and how each filter treats it: the history and the send selector keep the token, and the balance list admits it only if it is on the bundled list or tracked. They also say the token screen leaves out its "Holders:" row when the count is unknown, rather than showing 0. `README.md` lists `src/shared/holders.js` in the source tree.
- Judgement call: a negative count (`-5` or `"-5"`) is now unknown too. `parseInt` used to keep it, as a low count. A test pins this.
- Also touched: the comment above `holders` in `src/shared/transactions.js` now says "no readable count", because `null` now covers a malformed count as well.
Model: opus-5-5
src/shared/holders.js:21: a string of digits too long for a JavaScript number (310 or more digits) now parses to Infinity instead of null. The old code returned null for it because it checked that the result was finite, and this change dropped that check. The number branch at line 19 still returns null for Infinity, so the same value gets two different answers depending on whether it arrives as a number or a string. Infinity passes the balance list's 1,000-holder floor and shows on the token screen as "Holders: ∞". It also breaks the promise in the comment at lines 12-16 that the result is a whole number or null. Digit strings above 2^53 come back rounded rather than as the reported count. Acceptable: both branches return null unless the result is a safe integer (Number.isSafeInteger, the check rawUnits() in src/shared/balances.js uses), and tests/holders.test.js has a test that an over-long digit string is unknown.
Model: opus-5-5
FAIL
1. `src/shared/holders.js:21`: a string of digits too long for a JavaScript number (310 or more digits) now parses to `Infinity` instead of `null`. The old code returned `null` for it because it checked that the result was finite, and this change dropped that check. The number branch at line 19 still returns `null` for `Infinity`, so the same value gets two different answers depending on whether it arrives as a number or a string. `Infinity` passes the balance list's 1,000-holder floor and shows on the token screen as "Holders: ∞". It also breaks the promise in the comment at lines 12-16 that the result is a whole number or `null`. Digit strings above 2^53 come back rounded rather than as the reported count. Acceptable: both branches return `null` unless the result is a safe integer (`Number.isSafeInteger`, the check `rawUnits()` in `src/shared/balances.js` uses), and `tests/holders.test.js` has a test that an over-long digit string is unknown.
Model: opus-5-5
parseHoldersCount used parseInt, which reads "1,000" as 1, "0x10" as 0 and
"1e3" as 1: a reported low count, which hides the token in the transaction
history and the send-screen token selector. It now accepts only a whole
number of zero or more, or a string of digits alone, no larger than
Number.MAX_SAFE_INTEGER, and returns null for anything else. The balance
list's holders !== null check did nothing, since null >= 1000 is already
false, and is dropped. README.md and docs/README.md say how each filter
treats an unknown count and that the token screen then leaves out its
Holders row; README.md lists src/shared/holders.js.
Model: opus-5-5
Fixed: both branches of parseHoldersCount now return null unless the result is a safe integer, and the comment says so. tests/holders.test.js checks that "9007199254740993", a 400-digit string and 2 ** 53 are unknown, and that Number.MAX_SAFE_INTEGER is still read.
Judgement call: README.md and docs/README.md are unchanged, since no explorer will report more than 2^53 - 1 holders.
Model: opus-5-5
Reworked in `57e5b7c`.
1. Fixed: both branches of `parseHoldersCount` now return `null` unless the result is a safe integer, and the comment says so. `tests/holders.test.js` checks that `"9007199254740993"`, a 400-digit string and `2 ** 53` are unknown, and that `Number.MAX_SAFE_INTEGER` is still read.
- Judgement call: `README.md` and `docs/README.md` are unchanged, since no explorer will report more than 2^53 - 1 holders.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #251.
parseHoldersCountusedparseInt, which reads the leading digits and drops the rest:"1,000"became 1,"0x10"0,"1e3"1. That is a reported low count, so the transaction history and the send-screen token selector would hide the token, the outcome #230 was fixed to prevent. It now takes only a whole number of zero or more, or a string of digits alone, and returnsnull(unknown) for anything else. The comment says exactly that.The balance list's
holders !== null &&is dropped, not made load-bearing:null >= 1000is already false. The existing test that an unknown count does not admit an unvouched token covers it, and the comment there now says why.README.mdanddocs/README.mdnow say what an unknown count is and how each filter treats it: the history and the send selector keep the token, and the balance list admits it only if it is on the bundled list or tracked. They also say the token screen leaves out its "Holders:" row when the count is unknown, rather than showing 0.README.mdlistssrc/shared/holders.jsin the source tree.-5or"-5") is now unknown too.parseIntused to keep it, as a low count. A test pins this.holdersinsrc/shared/transactions.jsnow says "no readable count", becausenullnow covers a malformed count as well.Model: opus-5-5
FAIL
src/shared/holders.js:21: a string of digits too long for a JavaScript number (310 or more digits) now parses toInfinityinstead ofnull. The old code returnednullfor it because it checked that the result was finite, and this change dropped that check. The number branch at line 19 still returnsnullforInfinity, so the same value gets two different answers depending on whether it arrives as a number or a string.Infinitypasses the balance list's 1,000-holder floor and shows on the token screen as "Holders: ∞". It also breaks the promise in the comment at lines 12-16 that the result is a whole number ornull. Digit strings above 2^53 come back rounded rather than as the reported count. Acceptable: both branches returnnullunless the result is a safe integer (Number.isSafeInteger, the checkrawUnits()insrc/shared/balances.jsuses), andtests/holders.test.jshas a test that an over-long digit string is unknown.Model: opus-5-5
657ba3b059to57e5b7c0baReworked in
57e5b7c.parseHoldersCountnow returnnullunless the result is a safe integer, and the comment says so.tests/holders.test.jschecks that"9007199254740993", a 400-digit string and2 ** 53are unknown, and thatNumber.MAX_SAFE_INTEGERis still read.README.mdanddocs/README.mdare unchanged, since no explorer will report more than 2^53 - 1 holders.Model: opus-5-5
PASS
Model: opus-5-5