mirror of
https://github.com/pezkuwichain/pezkuwi-wallet-android.git
synced 2026-07-22 20:45:53 +00:00
pezkuwichain
9a11dc2c3d
Found on a real device: opening the backup/export screen for an existing wallet crashed with java.lang.IndexOutOfBoundsException: Cannot read 412 of 412 at .../scale/dataType/optional.read at .../scale/Schema.read (x3) at SecretStoreV2$getMetaAccountSecrets$2.invokeSuspend Root cause: MetaAccountSecrets is a positional (SCALE) binary schema. optional<T>.read() unconditionally reads a presence-flag byte with no EOF handling - reading a blob that predates a trailing field (written before that field existed) throws instead of yielding null. This is also why Solana's own address was never getting backfilled: the migration's own read of the account's stored secrets was throwing on every attempted run, silently caught by its own per-account try/catch. Confirmed via substrate-sdk-android's actual source (Dsl.kt/Delegate.kt) that Tron/Bitcoin's identical schema-growth pattern carried the exact same latent risk - it likely only avoided crashing so far by chance byte-alignment in previously-stored blobs, not because the format tolerates it. Fix: read Tron/Bitcoin/Solana's keypair/derivationPath fields (every field added after the original Substrate+Ethereum schema) through a SafeOptional DataType that catches a failed read and returns null, via the library's own custom() field-declaration escape hatch. Write behavior is byte-for-byte unchanged - only reading a shorter/older blob now correctly yields null for fields it doesn't have, instead of crashing every caller of getMetaAccountSecrets (balance sync, signing, backup/export, this Solana backfill migration itself).