fix(sdk): stop sending account names the node refuses to parse - #1407
Conversation
An account name is a fixed_string of 16 bytes, and hived asserts on the byte
length while deserialising the argument, before it looks anything up. So an
over-long value is not "no such account", it is
Assert Exception:in_len <= sizeof(data): Input too large: `<value>` (17)
for fixed size string: (16)
and it comes back from plain reads too: lookup_accounts, get_accounts and
get_account_reputations all take an account_name_type.
The editor's `@` autocomplete hands lookup_accounts whatever follows the `@`,
so `@aliveandthriving,` written in prose arrives with its comma attached. That
is the bulk of the reports. It surfaced unhandled because the await sits in a
setTimeout callback inside a Promise executor with nothing catching it.
The guard counts bytes rather than characters, which is where a `.length <= 16`
check misses: `sebastián.bilbao` is 16 characters and 17 bytes, `вцпк33ппп43` is
11 characters and 18 bytes. Both were reported by the node as 17 and 18.
It is a length gate, not name validation. A prefix search may legitimately ask
about something that is not a valid name, and the node answers that with no
matches. get_accounts drops only the offending entries, since one bad name
asserts the whole batch.
The `@` dataProvider now resolves to no suggestions when a lookup fails, so a
failure cannot escape as an unhandled rejection.
Fixes #1403
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (7)
📒 Files selected for processing (13)
📝 WalkthroughWalkthroughThe SDK now rejects empty or over-limit account names before RPC calls, filters invalid names from batches, and adds regression tests. Web autocomplete converts lookup failures into empty results. SDK and wallets versions increase by one patch release. ChangesAccount queryability safeguards
Estimated code review effort: 3 (Moderate) | ~20 minutes Poem
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint install failed. For unrecoverable errors, disable the tool in CodeRabbit configuration. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Fixes #1403
Roughly 20 Sentry groups since May, all of the form
RPCError: Assert Exception:in_len <= sizeof(data): Input too large: <value> (17) for fixed size string: (16).What actually happens
An account name is a
fixed_stringof 16 bytes. hived asserts on the byte length while deserialising the argument, before it looks anything up, so an over-long value is not answered with "no such account", it is answered with the assert. That applies to plain reads as much as to a broadcast, becauselookup_accounts,get_accountsandget_account_reputationsall take anaccount_name_type:The
@trigger intextarea-autocompletehandslookup_accountswhatever follows the@up to the next whitespace, withminChar: 2as the only guard, so prose punctuation rides along. That accounts for the reported values and for the culprit URLs (entry pages for the reply box,/submitand/draft/<uuid>for the editor):@aliveandthriving,->aliveandthriving,@minismallholding!->minismallholding!@isaacmartiubeda(64)->isaacmartiubeda(64), a username pasted along with its rendered reputation badgeIt reached Sentry as
mechanism: onunhandledrejection, handled: nobecause theawaitsits in asetTimeoutcallback inside anew Promiseexecutor, where nothing catches it.The check has to count bytes
This is the part a
.length <= 16check gets wrong, and the numbers hived reports are byte counts:aliveandthriving,sebastián.bilbaoвцпк33ппп43Changes
isQueryableAccountNamein the SDK accounts utils, a byte-length gate.lookupAccountsQueryOptionsandgetAccountReputationsQueryOptionsresolve to no matches instead of making the call. For a lookup that is the honest answer, and it is what every caller already handles.getAccountsQueryOptionsdrops only the offending entries, since one bad name asserts the whole batch. A caller asking "does this account exist" gets the empty result it already handles, and a batch with one good name still returns it.@dataProvider resolves to no suggestions when a lookup fails, so nothing can escape as an unhandled rejection.This is deliberately a length gate and not account-name validation. A prefix search is allowed to ask about something that is not yet a legal name, and the node answers that with no matches. The only thing that must not happen is a request the node refuses to parse.
Worth noting separately:
getUsernameErrorinapps/web/src/utils/username-validation.tsusesusername.length > 16, and the referral field on/signup/freeis character-length checked with no charset check. Those inputs now reach a guarded query rather than the node, but the messages they show a user could be better. Left alone here.Verification
pnpm --filter @ecency/sdk test— 723 passed (52 files). Newaccount-name-query.spec.tscovers the byte counts of the exact values that reached production and the cases a character check would let through;lookup-accounts-query-options.spec.tsand the additions toget-accounts-query-options.spec.tsassert the node is not called at all for those, and that a mixed batch still queries the good name. Reverting the three query files leaves exactly those four query-level cases red.pnpm --filter @ecency/web test— 2596 passed (271 files).pnpm typecheck— clean.pnpm lint— clean.apps/self-hostedbuilds andcheck-node-globalsreports 3 chunks clean, since this touches package code. The guard usesTextEncoder, not a Node global.dist/is not rebuilt here, that stays label-gated.Summary by CodeRabbit