The horns were touching the canvas corners - looked cramped and got cropped
tightly by circular/squircle adaptive-icon masks on real devices. Now
scaled to 62% of the canvas and centered on transparent padding, matching
how other apps' icons actually look on a real home screen.
BRIDGE_ADDRESS_GENERIC was still the retired legacy single-key bot's
address (5C5CW7xD...), not the real 3-of-5 multisig custody
(BridgeMultisigConstants.MULTISIG_ADDRESS). Confirmed live: a real user
swap sent there landed at the dead address and was never detected by
usdt-bridge's listener (which only watches the multisig account). Funds
were recovered separately using the still-intact legacy seed; this fixes
the actual destination so future swaps land where the listener watches.
Also added the user-confirmed Kurmancî translation for
bridge_wusdt_to_usdt_blocked (values-ku), replacing the now-stale text left
untouched in the previous commit pending native review.
Source updated in pwap-web/shared/images/pezWallet.png - simpler design,
no border/text baked in this time. Regenerated the same way as the first
icon pass: padded to square, resized per density into every existing slot.
BridgeViewModel's wUSDT->USDT gate called http://217.77.6.126:3030/status -
the legacy single-key bridge bot's endpoint. That service was stopped this
same session (see res/validators-tiki.md), so the check always threw,
always caught, and always reported "inactive" - the red warning reflected a
dead dependency, not real reserve state.
Replaced with a direct on-chain read of the multisig's actual USDT balance
on Polkadot Asset Hub (BridgeMultisigInteractor.getPolkadotUsdtReserve, via
a new Assets.Account storage query mirroring the existing Approvals one).
The gate is now per-request: a specific withdrawal is blocked only if it
exceeds the real reserve, not on a global on/off flag requiring full 1:1
parity between total circulating supply and total reserve - matching how
the Rust listener's own reserve-shortfall check already works. Re-checked
on every amount change, not just once per screen load.
bridge_wusdt_to_usdt_blocked now takes the available reserve amount as a
parameter; updated the English and Turkish strings. Left values-ku
untouched deliberately - not fabricating Kurdish translation text without
native review.
Source: pwap-web/shared/images/pezWallet.png. Padded to square (source is
979x1053, corners already fully transparent so the padding is seamless),
then resized per density into every existing icon slot - legacy ic_launcher/
ic_launcher_round and the adaptive foreground layer all use the same full
graphic, matching how the previous icon was already structured; the solid
dark adaptive background layer is untouched since it's still a compatible
fill color for the new logo.
Server-side (pezbridge_bot_config.json, usdt-bridge's bridge_config.json)
was already bumped to a 40,000/200,000 wUSDT renewal threshold/topup this
session, but this app's own BridgeMultisigConstants still had the old
3,000/10,000 values - it construct/checks the exact same on-chain call, so
the mismatch wasn't just a stale display, it meant a signer's app would
consider a 20,000-remaining allowance "fine" while PezbridgeBot was already
paging everyone to renew it.
The DOT<->HEZ bridge backend (the legacy single-key bot) is being
permanently decommissioned - it had zero multisig protection and no
liquidity gate at all on that leg (unconditionally "active" regardless
of pool state, the single least-safe path in the whole bridge). Once
USDT bridging is solid, HEZ is reachable indirectly (bridge USDT, swap
for HEZ within Pezkuwi's own ecosystem) without a dedicated native
bridge that would need its own from-scratch security work (native
currency has no Assets.approve_transfer-style delegation to reuse).
- BridgePair/BridgeDirection collapsed to USDT-only (USDT_TO_WUSDT/
WUSDT_TO_USDT) - kept the pair/pairOptions/picker structure itself
since it costs nothing and is the natural seam for a future pair,
rather than hardcoding a single value inline.
- Removed the now-dead DOT/HEZ exchange-rate fetching (CoinGecko
polling, fallback rate) and liquidity-gate logic entirely, not just
the unreachable enum branches.
- Removed the separate "Bridge DOT ↔ HEZ" entry from the asset
selector bottom sheet (BuySellSelectorMixin) - both it and "Bridge
USDT" opened the exact same screen with no preset, so keeping a
DOT-HEZ-labeled entry pointing at a USDT-only screen would have been
actively misleading, not just redundant.
- bridge_title was the generic toolbar/picker-sheet title but hardcoded
"DOT ↔ HEZ Bridge" regardless of pair - fixed to "USDT Bridge".
- Removed now-unreferenced strings (wallet_asset_bridge,
bridge_pair_dot_hez, bridge_rate_format(_reverse),
bridge_hez_to_dot_note/warning/blocked) from the base strings.xml.
Confirmed via research: feature-bridge-api/feature-bridge-impl modules
exist but are unrelated orphaned scaffolding, not depended on by :app,
zero code overlap with this screen - correctly out of scope here.
Aleph Zero's only configured public node (wss://ws.azero.dev) is
currently down (confirmed via direct WebSocket handshake - real,
external, isolated outage on their side, chain itself is healthy and
active). No free/working alternative public RPC was found to add as
failover. Rather than hard-fail CI on an external dependency neither
our code nor config controls, convert connectivity-class exceptions
(TimeoutCancellationException, directly or wrapped) into a JUnit
assumption-skip - this mirrors how production balance-sync code
already isolates per-chain RPC failures instead of treating them as
hard errors. A real bug (bad decoding, wrong assertion, etc.) still
fails the test exactly as before.
QueryableStorageEntry2 has always had a single-key-tuple query(k1, k2)
alongside entries()/keys(), but QueryableStorageEntry3 only ever grew
entries()/keys() - nothing in the codebase needed a direct 3-key point
query until BridgeMultisigRuntimeApi's Assets.Approvals lookup. Added
query(k1, k2, k3), mirroring QueryableStorageEntry2's implementation
exactly.
PR #13 fixed this for android_build.yml's Gradle invocation, but
code-quality.yml's ktlint job runs its own separate ./gradlew ktlint
without the same env passthrough - runtime/build.gradle reads this
secret unconditionally during project configuration, so ktlint failed
outright as soon as Tron support (which needs it) was merged into
this branch.
- module(Modules.X) needs substrate_sdk_android's module() extension
imported explicitly, not just the Module type.
- accountIdIn is a MetaAccount member, not a top-level import.
- submitExtrinsicAndAwaitExecution(...).requireOk() resolves to the
Result<T>-preserving overload, so wrapping it in runCatching produced
Result<Result<T>>; unwrap with getOrThrow() first so the T-returning
overload applies.
Card now opens in a slim single-line pill showing only Trust Score.
Tapping it expands to the full card (citizen status, world Kurdish
count, referral actions); a chevron in the expanded header collapses
it back. Expand state persists across scroll/recycling within the
session but resets to collapsed on a fresh app launch.
Any of the USDT bridge multisig's 5 known signatories now sees a
status button on the Bridge screen: green when the automation key's
spending allowance is healthy, red with a Sign action once it drops
below threshold. Signing submits the renewal's as_multi approval
directly from the wallet, mirroring the same on-chain action already
available via pwap-web and pezbridge-sign.pex.mom - a third
independent channel for the same operation, none of which is a
single point of failure.
CI caught this: depositorAccountModel's inner type became AccountModel?
when the depositor field went nullable, but onDepositorClicked still
called it.address() directly instead of null-checking first.
The pending-operation model assumed a call already exists on-chain
(Multisig.Multisigs entry with a Timepoint) before it could be
reviewed or signed. A signatory who is the first to see a brand-new
call - reachable via the deep link before anyone has submitted
anything - hit "operation not found" and the screen refused to open,
even though the deep link already carried the call's data in its
callData param (previously decoded only to format Executed/Rejected
dialog text, then discarded for the Active case that needed it).
- PendingMultisigOperation.timePoint/depositor are now nullable to
represent "not yet submitted"; composeMultisigAsMulti's
maybeTimePoint parameter already accepted null (used for ordinary
first-time multisig-origin submissions via MultisigSigner), so the
pallet-call layer needed no changes.
- New PendingMultisigOperation.notYetSubmitted(...) factory and
MultisigOperationDetailsInteractor.buildNotYetSubmittedOperation()
build a synthetic operation from the deep link's callData, hash
verified against the URL's callHash rather than trusted blindly.
- OperationIsStillPendingValidation now skips its on-chain
"still pending" check for a not-yet-submitted operation, since it
would otherwise always fail and block the very first submission.
- MultisigOperationPayload carries the callData through so both the
details screen and the full-details screen (independently reachable
via "Call Details", since that button is available whenever call
data is known) can construct the synthetic operation.
The Bridge screen let a user type any amount and enabled the Swap
button regardless of what they actually held, unlike the Swap screen
which shows a live "Max: X" and disables on overflow. The confirm-step
ValidationSystem would still catch it before signing, but only after
routing through Send - no immediate feedback on the Bridge screen
itself.
Wires WalletInteractor.assetFlow(chainId, assetId) to the currently
selected origin side (re-subscribed on every direction/pair change),
tracking Asset.transferable - the same field the real transfer
validation checks. Reuses the existing MaxAmountView/MaxAvailableView
widget the Swap screen already uses for the "Max: X" display, and adds
a matching error-bordered state to BridgeAssetInputView. The
"Insufficient balance" string (bridge_insufficient_balance) was
already translated into every locale but never wired to any code.
The redesigned Bridge cards resolved asset icons via the chain-icon
helper (asset.icon.asIconOrFallback()), which treats the value as a
ready-to-load URL. Chain.Asset.icon is frequently a bare filename
resolved through AssetIconProvider's base-URL/color-mode logic, so
any asset relying on that path rendered a blank icon (Polkadot Asset
Hub's USDT, and the DOT/HEZ utility assets on the affected side).
Switched to assetIconProvider.getAssetIconOrFallback(asset), the same
path every other asset row in the app uses.
Also switched the card subtitle from chain.name to
chain.displayNameWithAssetStandard(), so Pezkuwi Asset Hub shows its
PEZ-20 token-standard label, matching Send/Receive/the balance list.
Replaces the segmented pair/direction buttons and plain-text amount
sections with token-icon cards (BridgeAssetInputView), a one-tap flip
button, and a bottom-sheet pair picker (BridgePairListBottomSheet).
BridgeViewModel gains only additive presentation data (fromCard/toCard/
pairOptions, derived from the existing pair/direction state and the
same chainId/assetId mapping swapClicked() already used) - all bridge
business logic (rate, fee, minimum, liquidity warnings, submission)
is unchanged.
Confirmed live via logcat: tapping "send" to a P2SH address force-closed
the app - FATAL EXCEPTION: IllegalArgumentException: Bech32 string is
mixed case, thrown from Chain.accountIdOf() -> bitcoinAddressToAccountId()
(native-SegWit-only) via the Confirm Send screen's address icon generator,
a completely separate call path from the transaction-building fix already
shipped. Chain.accountIdOf() now falls back to decodeBitcoinDestination()
for P2SH/P2PKH, safe here because this generic accountId is only ever used
for opaque purposes (identicons, presence checks) - the real send path
already bypasses it entirely and builds the scriptPubKey straight from the
typed BitcoinDestination.
CI caught a redeclaration - Base58Check is already a chain-agnostic object
in this same package (TronAddress.kt), used for Tron's own Base58Check
addresses. Bitcoin's legacy addresses are the same shape (1 version byte +
20-byte hash), just a different version byte - reuse it directly.
Confirmed live via logcat: the real "QR can't be decoded" error was
neither a QR format issue (the earlier BIP21 fix, while correct, wasn't
the cause here) nor a scan failure - the raw QR content was a bare P2SH
address (3...), which this wallet's native-SegWit-only address validation
rejected outright. A real exchange (OKX) withdrawal address turned out to
be P2SH-only with no way to request native SegWit instead.
Adds Base58Check decoding and BitcoinDestinationAddress.kt (P2WPKH/P2SH/
P2PKH, each producing the correct scriptPubKey shape - these differ from
each other, not just cosmetically). This wallet's OWN address/derivation
stays native-SegWit-only and untouched (bitcoinAddressToAccountId is
unaffected) - only the SEND path now recognizes wider destination types.
BitcoinTransactionService/RealBitcoinTransactionService now take the raw
recipient address string instead of a pre-resolved AccountId - converting
to AccountId this early would have discarded which script shape the
destination actually needs, silently building a P2WPKH output for a P2SH
recipient (a real fund-misdirection risk, not just a validation gap).
Test vectors: Satoshi's genesis P2PKH address, a well-known P2SH vanity
address, and the real OKX withdrawal address from this session's live QR
scan, all cross-verified against an independent Python implementation
before writing the Kotlin equivalent.
Reverts the temporary QrDiag logging added to find this - no longer needed.
Neither the raw scanned QR string nor the InvalidFormatException from a
failed decode was ever logged - the failure path only shows a generic
toast, making it impossible to diagnose from logcat alone. Temporary,
will revert once the actual failure is identified.
Confirmed live: sending BTC back out via QR-scanning an external wallet's/
exchange's receive address failed with a generic "QR can't be decoded"
error. Root cause: the QR decoder only ever recognized two shapes -
substrate:<address>:<pubkey> triples and bare address strings - neither of
which matches the bitcoin:<address>?amount=... BIP21 URI most wallets and
exchanges generate for a BTC address. Adds BitcoinUriQrFormat, tried
alongside the existing formats, that strips the scheme and query string
before validating the address the normal way.
Test predates the isBitcoinBased field (added on the Bitcoin branch after
Tron's send branch already had this test file) - CI caught the missing
constructor argument.
The merge silently combined two independent additions of the same
dependency (my fun signerProvider() and Tron's val signerProvider) since
they landed on non-conflicting lines - Dagger correctly caught this as
[Dagger/DuplicateBindings]. Keeping Tron's val form, since it was already
CI-verified on that branch.
Bitcoin was branched off main independently instead of continuing on top
of the Tron send branch, which caused real divergence: both branches touch
the same shared signing/DI code (multiChainEncryptionFor, getMetaAccountKeypair,
NodeHealthStateTesterFactory, AssetsModule/TypeBasedAssetSourceRegistry,
CloudBackup schema, Fee model), and both need to ship together in one
coordinated release once wallet-util's master is unblocked. Merging now
reconciles that before it gets any harder, and gives one branch/versionCode
history for device testing instead of two that silently diverge.
Conflict resolutions of note:
- SecretStoreV2/SecretsSigner: getKeypair and multiChainEncryptionFor now
recognize Tron AND Bitcoin accounts (isTronBased/isBitcoinBased both
threaded through, checked before the Ethereum fallback).
- AccountDataSourceImpl: both address-backfill migrations now run
sequentially in one coroutine (Tron's fix for a race against the legacy
migration applies equally to Bitcoin's backfill).
- CloudBackup: kept Tron's forward-looking Solana schema reservation
alongside Tron's and Bitcoin's now-real fields.
- ChainRegistryModule/NodeHealthStateTesterFactory: adopted Tron's
self-contained short-lived OkHttpClient (simpler than threading the
shared app-wide client through RuntimeDependencies, which is reverted).
- RealSecretsMetaAccount: extended Tron's chain-account MultiChainEncryption
fix to also cover Bitcoin, for the same underlying reason.
- ChainExt.isValidAddress: Tron's branch independently closed the
pre-existing Tron validation gap; kept alongside Bitcoin's own check.
wallet-util's master lacks the Tron/Bitcoin chain config (reset to the last
Play-Store-compatible state, see wallet-util history around 2026-07-11) -
this mirrors the exact override feature/trc20-tron-send used, so a real
device build can see the Bitcoin chain entry. MUST be reverted to master
before this branch merges.
CI caught [Dagger/MissingBinding] for SignerProvider in
WalletFeatureComponent - AccountFeatureApi already exposes it, but
WalletFeatureDependencies (feature-wallet-impl's own dependency interface)
never re-declared it, so it wasn't reachable by BitcoinAssetsModule's
provideBitcoinTransactionService.
RealBitcoinTransactionService builds and signs native SegWit transactions
client-side (mempool.space only exposes UTXOs/fee-rate/broadcast, not
construction, unlike TronGrid): greedy largest-first UTXO selection over
confirmed UTXOs, inputs*68 + outputs*31 + 11 vsize heuristic for fees
(matching pezkuwi-exchange's proven approach), RBF-signaled inputs, and a
546-sat dust threshold that folds sub-dust change into the fee rather than
creating an uneconomical output.
Each input gets its own BIP143 sighash, signed via the existing raw-hash
signing primitive (NovaSigner.signRaw with skipMessageHashing) already used
for Ethereum/Tron, then DER-encoded with low-S normalization - no new
signing call path was added, only the DER encoding step.
Also fixes multiChainEncryptionFor/getMetaAccountKeypair to recognize
Bitcoin accounts: previously neither function had any Bitcoin (or Tron)
branch, so signing would have silently used the wrong keypair. Threads a
bitcoin flag through mapMetaAccountSecretsToKeypair/DerivationPath and
AccountSecrets.keypair(chain)/derivationPath(chain) the same way ethereum
already is.
CI caught onChainAssetId's when as non-exhaustive; a codebase-wide sweep
for every other exhaustive when on Chain.Asset.Type found one more
(existentialDepositError in Common.kt) that would have failed the same way.
CI caught "no parameter with name 'bitcoinAddress'" in AccountMappers.kt -
every other MetaAccount subclass got these constructor params threaded
through in the Phase 2 batch, but PolkadotVaultMetaAccount only got the
isBitcoinBased guard in supportsAddingChainAccount(), not the params.
Adds a mempool.space-style REST client (RealBitcoinApi, with the same
retry-on-429 pattern as TronGridApi), a polling AssetBalance implementation,
and BitcoinNodeHealthStateTester so the Networks screen can show live
health for Bitcoin nodes (mirrors TronNodeHealthStateTester's rationale:
mempool.space speaks plain REST, not JSON-RPC, so the existing Ethereum/
Substrate testers can't be reused).
Wires Chain.Asset.Type.BitcoinNative through the asset-type mappers and
TypeBasedAssetSourceRegistry, and BitcoinAssetsModule into AssetsModule -
transfers/history stay on the Unsupported stubs until send support lands.
CI caught 5 unresolved references (toBitcoinAddress, bitcoinAddressToAccountId,
emptyBitcoinAccountId, bitcoinPublicKeyToAccountId, isValidBitcoinAddress) -
the functions existed in common/utils/BitcoinAddress.kt but were never
imported here.
Derives a BIP84 (native SegWit) keypair alongside the existing substrate/
ethereum/tron ones, stores it in MetaAccountSecrets/CloudBackup, persists
bitcoinPublicKey/bitcoinAddress on meta_accounts (DB migration 74->75), and
threads isBitcoinBased through Chain/ChainLocal/mappers/ChainExt/ChainRegistry
the same way isTronBased was wired. Adds BitcoinAddressBackfillMigration,
mirroring TronAddressBackfillMigration, so existing wallets get a Bitcoin
address without re-import.
Input 0's sequence was set to 0xeeffffffL, but BIP143's doc shows "eeffffff"
as the on-wire (little-endian) bytes, not the integer value - the correct
value whose LE encoding is eeffffff is 0xffffffee, not 0xeeffffff. Caught by
CI: 83/84 common module tests passed, only bip143Sighash failed. Isolated by
building a standalone Kotlin+JDK repro outside Gradle/Android (no JDK available
in this environment) - every other intermediate value (hashPrevouts, outpoint,
scriptCode, hashOutputs) matched BIP143 exactly; only hashSequence was wrong,
narrowing it to this one transcription error rather than the implementation.
Phase 1 of native BTC send/receive support (native SegWit/P2WPKH only, bc1q...
addresses - Taproot and legacy/P2SH-SegWit explicitly out of scope). Hand-rolled
since no Bitcoin library exists on this project's classpath (bitcoinj/PSBT/Base58/
Bech32) - same rationale as this session's Tron work needing its own Base58Check.
- Bech32/Bech32m codec (BIP173/BIP350) + segwit address encode/decode
- DER ECDSA signature encoding with BIP62 low-S normalization
- HASH160/P2WPKH scriptPubKey construction and address<->accountId conversion
- BIP143 sighash computation and raw segwit transaction serialization
Every primitive is verified byte-for-byte against official BIP173/BIP350/BIP143
test vectors (fetched directly from github.com/bitcoin/bips at implementation
time) - see each *Test.kt's doc comment for exact vector provenance. No JDK is
available in this environment to run these locally; also cross-verified via an
independent Python transliteration of each function before committing.
Isolated from the Tron feature branch so it can land on main independently -
android_build.yml is a reusable workflow pinned to @main by every caller, so a
secret it doesn't declare/pass through never reaches the build regardless of
which branch's source gets checked out.
Complements the retryOn429 fix - having a key means requests are far less likely to hit
the rate limit at all, rather than just retrying transparently after they do. Wired the
same way as INFURA_API_KEY/DWELLIR_API_KEY: buildConfigField read from local.properties or
CI secret, added TRONGRID_API_KEY to android_build.yml's secret passthrough (every caller
already uses secrets: inherit, so no per-workflow changes needed beyond this).
TronGrid's public (no API key) endpoint rate-limits aggressively under normal, human-paced
usage - confirmed live during send-flow testing, where every Confirm tap (each re-running
fee estimation + broadcast) started hitting bare 429s after only a few attempts, with no
way through except retrying by hand until one happened to land outside the rate-limit window.
Added retryOn429 (exponential backoff, same shape as the existing test-only helper in
TronBalancesIntegrationTest) at the RealTronGridApi level so every call - fee estimation,
broadcast, balance reads - retries transparently. Broadcast is safe to retry on 429
specifically since it means TronGrid rejected the request before processing it, not that
the transaction may already be in flight.
SecretsSigner.multiChainEncryptionFor() only recognized substrate accounts, standard
Ethereum accounts, and explicit per-chain override accounts. A Tron account's accountId
matches none of those (same secp256k1 scheme as Ethereum, but a different SLIP-44 derivation
path/keypair), so it fell through to null and crashed on the `!!` - found live testing the
send flow end-to-end, reproduced on every Confirm tap.
Fixing just the null case would have signed Tron transfers with the Ethereum keypair
instead of the Tron one (getMetaAccountKeypair only distinguished ethereum/substrate),
producing an invalid signature. Threaded a proper isTronBased flag through
down to mapMetaAccountSecretsToKeypair so Tron gets its own MetaAccountSecrets.TronKeypair.
TronGrid's createtransaction rejects amount=0 with a ContractValidateException.
estimateNativeFee called it unguarded (unlike the TRC-20 path, which already
wraps its dry run in runCatching), so the send screen's reactive fee loader
surfaced this as a generic "Network not responding" error whenever it ran
before the user typed an amount - found live testing the send flow end-to-end.
Trc20AssetBalance/RealTronGridApi.fetchTrc20Balance() read through
TronGrid's /v1/accounts/{address} REST endpoint - but a TRC-20 balance
lives entirely in the token contract's own storage, not the holder's
Account object. An address that has only ever received TRC-20 tokens
(never native TRX, never otherwise "activated" on-chain) has no Account
object at all, so /v1/accounts silently returns `data: []` for it
regardless of its real token balance, and the old code treated that the
same as a genuinely empty/zero account.
Found via a live test: a real wallet received 5 USDT-TRC20, the exchange
confirmed the transfer complete on-chain, but the app kept showing 0.
Independently verified live: /v1/accounts returned empty for the address,
while a direct balanceOf(address) contract call (triggerconstantcontract)
correctly returned 5000000.
Rewrote fetchTrc20Balance() to read via balanceOf(address) instead -
reuses the existing triggerConstantContract() call already used for TRC-20
transfer fee estimation, plus a new encodeBalanceOfParameters() ABI helper
alongside the existing transfer() one. Added a regression test pinned to
this exact real address/balance so this can't silently regress again.
The Send/Receive/etc. network picker (NetworkFlowViewModel) already showed
"Ethereum (ERC-20)"/"Tron (TRC-20)" for a multi-chain token's per-chain rows,
but the main Assets dashboard's own expandable per-token breakdown (tap a
token like USDT to see every chain it exists on) is a completely separate
code path (TokenAssetMappers/TokenAssetViewHolder) that still showed a bare
chain name - found via a real device screenshot of that specific screen.
Moved the shared display-name-with-label logic to a public extension
(Chain.displayNameWithAssetStandard(), runtime/ext/ChainExt.kt) so both
screens build the exact same string instead of duplicating (and now
diverging) the same logic twice.
wallet-util's master/main got reset to the last content the still-live
Play Store release can parse (see wallet-util repo history around
2026-07-11 - an unrelated production incident, not a regression on this
branch). master no longer serves Tron config/icons, so this branch's test
builds would silently regress to "no Tron" - not because of anything wrong
here, but because the shared config source moved out from under it.
pending/post-fix-release preserves exactly what master had before the
reset. MUST be reverted to "master" before this branch is merged - this
override should never ship.
A single malformed or not-yet-understood remote chain/asset entry used to
abort the whole sync via a plain .map{} - chainDao.applyDiff() never even
gets called, so a brand new install (empty local DB) ends up with zero
cached chains forever, i.e. a completely empty tokens list, until the
remote data or the app's parsing code changes. This is exactly what
happened in production: master's config received a batch of upstream
changes the still-live app version couldn't parse, and every fresh install
got stuck with a blank list while existing installs (which already had a
populated local DB from a prior successful sync) were unaffected.
Mirrors the same mapListNotNull + runCatching pattern already used on the
read side (ChainRegistry.currentChains) - one bad chain, or one bad asset
within an otherwise-fine chain, is now logged and skipped instead of taking
the rest of the sync down with it.
nodesHealthState() only ever looked at wssNodes(), so an HTTPS-only chain
(Tron - no wss endpoint at all) always got an empty node list here: the
enable/disable switch itself worked correctly (it reads/writes
chain.isEnabled directly, unrelated to this list), but with nothing ever
rendering underneath it, the screen looked frozen/unresponsive - this is
almost certainly why a single real toggle needed several taps to land
correctly, since there was no visible confirmation whichever tap actually
took effect.
Falls back to httpNodes() when a chain has no wss nodes, and adds a real
TronNodeHealthStateTester (GET /wallet/getchainparameters, needs no address)
instead of naively reusing EthereumNodeHealthStateTester's eth_getBalance
call, which TronGrid doesn't speak and would have always reported the node
as down regardless of its actual health.
The per-chain list shown when picking an action (Send/Receive/Swap/Buy/Sell/
Gift) for a token that exists on multiple chains (e.g. USDT) now orders
Ethereum and Tron right after the existing Pezkuwi/Polkadot/Kusama priority
chains instead of falling into the alphabetical "everything else" bucket,
and appends a token-standard label - "(PEZ-20)"/"(ERC-20)"/"(TRC-20)" - to
disambiguate which issuance this is, since a bare chain name alone doesn't
convey that.
The label is intentionally chain-specific, not derived from Chain.Asset.Type,
since every Statemine-type chain (Polkadot AH, Kusama AH, Pezkuwi AH) shares
the same asset type but only Pezkuwi AH's issuance needs the PEZ-20 label.
TronAddressBackfillMigration was gated behind a global SharedPreferences
flag ("has this migration ever run on this install") rather than checking
per-account whether a Tron keypair is actually missing. Once that flag was
set - even by a run that found nothing to fix, or partially failed - the
migration never ran again on that install, so an account that lost its Tron
keypair some other way (the cloud-backup schema gap fixed in c78b325) could
never be repaired without a fresh reinstall.
backfillIfNeeded() already does a cheap, correct per-account check (skips
instantly if the account already has a keypair, isn't SECRETS-type, has no
entropy, etc.), so there's no need for an outer one-shot gate at all - just
run it unconditionally on every app start.
WalletPublicInfo/WalletPrivateInfo had no tron field at all, so any wallet
created via the (default) cloud-backup wallet creation flow, or restored
from a cloud backup, silently lost its Tron address and keypair even though
AccountSecretsFactory/SecretsMetaAccountLocalFactory derived them correctly
moments earlier - this is why TRX/USDT-TRC20 never appeared for any wallet,
new or old, confirmed via a device-side diagnostic dump of the actual DB row
(tronAddress=NULL) after a fresh wallet creation.
Also reserves (but does not wire up) solana/bitcoin fields in the same
schema, since native derivation for those doesn't exist yet - adding them
now means that work won't need another silent-drop-prone pass through this
same schema later.
Adds a regression test exercising the exact apply-diff path that lost the
data, plus tron support in the shared cloud-backup test builder DSL.
hasAccountIn=false was observed live for the currently active account despite
every derivation/mapping code path (creation, backfill, DB->domain mapping)
tracing correctly - need to see the actual DB state per account to know
whether this is a write-time or read-time gap.
TRX is completely absent from the Assets list even for a brand-new
wallet on a completely fresh install - ruled out per-account backfill
(fresh wallet correctly derives tronAddress) and stale per-device chain
state (fresh install, no carried-over connectionState). Need to see
empirically whether the Tron chain even reaches currentChains at all,
and if so, which of hasAccountIn/connectionState.isDisabled gates it.
Log.d/Log.e added to TronAddressBackfillMigration throw 'Method ... not
mocked' in plain JVM unit tests without this - the framework's own stubs
are meant to be configured this way for exactly this case, not worked
around by avoiding Log calls in production code.
TRX still missing on a real device after installing the backfill fix,
with no way to tell whether the migration ran, skipped, or threw for that
specific account - the migration had zero logging. Adds Log.d at every
decision point (per-account skip reason, success) plus a try-catch around
each account so one account's failure can't silently abort the whole
migration or crash app startup for everyone else.
@Before's preferences.getBoolean stub was never invoked by migrate()-only
tests (only migrationNeeded() reads that preference), tripping Mockito's
strict-stubs UnnecessaryStubbingException across the whole class. Moved
it into a dedicated migrationNeeded() test, matched via any() rather than
the production class's private preference-key constant (which isn't
visible here), and added the missing assertTrue import.
Found via manual device testing against a real, pre-Tron production
wallet: TRX/USDT-TRC20 didn't appear anywhere in the Assets list, not
even as a zero balance - unlike every other configured chain (KSM, USDC,
ETH, BNB, AVAX, LINK all show up at 0). Root cause: MetaAccount.hasAccountIn()
gates Tron balance sync on tronAddress != null, but tronAddress is only
ever populated once, at fresh-mnemonic-creation time in
AccountSecretsFactory.metaAccountSecrets(). The migration that added the
tronPublicKey/tronAddress columns (73_74_AddTronSupport) is pure ALTER
TABLE like every other migration in this codebase - it never derived a
value for pre-existing rows. Net effect: BalancesUpdateSystem silently
skips Tron entirely for every wallet that existed before this feature
shipped, with zero error surfaced anywhere. No automated test catches
this because every automated test creates a fresh (post-Tron) account -
this is exactly the class of bug that only manual testing against a real,
aged wallet can find.
Adds TronAddressBackfillMigration: a one-time, flag-gated pass (mirroring
the existing AccountDataMigration idiom) over SECRETS-type accounts that
still hold their mnemonic entropy in SecretStoreV2 but have no TronKeypair
yet. Derives the Tron keypair via AccountSecretsFactory.chainAccountSecrets
(isEthereum=true, same BIP32/secp256k1 path Tron already uses everywhere
else) at TRON_DEFAULT_DERIVATION_PATH - the same call fresh-account
creation already makes - so a backfilled wallet ends up with byte-for-byte
the same Tron address it would have gotten had it been created today, not
a separately-reimplemented derivation. Watch-only/Ledger/Json/multisig/
proxied accounts (never had a Tron-capable mnemonic) and raw-seed imports
(no entropy) are correctly left untouched, same as they already are for
Ethereum.
Includes a dedicated unit test asserting the backfill derives the exact
same reference Tron address (TUEZSdKsoDHQMeZwihtdoBiN46zxhGWYdH) that
TronDerivationTest already cross-validated against live TronGrid data for
the standard BIP39 test mnemonic - this touches real wallets' key
material, so it's pinned to a known-good vector rather than just asserting
against its own output.
Switching eq/any/argThat to the raw org.mockito.Mockito statics did not
avoid the 'eq(...) must not be null' crash (it moved from the @Test bodies
to the shared @Before setup(), since JUnit's @Before runs before every
test and failed first there) - Mockito.eq()/any() genuinely return null
regardless of which Kotlin entry point calls them, and that null still
gets checked once it flows into a Kotlin non-null-typed parameter
downstream. Local wrappers now guarantee a non-null return instead:
eq() falls back to the real passed-in value (harmless - the matcher is
already recorded on Mockito's thread-local stack by then), any()/argThat()
return an unchecked-cast dummy, mirroring mockito-kotlin's own internal
implementation of the same helpers.
Root cause of 'eq(...) must not be null' NPE: test_shared's eq()/any()/
argThat() are thin Kotlin wrappers with a declared non-null generic return
type T. Mockito.eq()/any() genuinely return null at runtime (that's how
their matcher-stack recording works) - fine when called directly from
Kotlin (a raw Java static call's return is a platform type, no null-check
inserted), but going through a Kotlin-declared wrapper whose T infers as
non-null at the call site (e.g. eq(baseUrl: String) here) gets a
compiler-inserted null-check on the wrapper's return, which then fires.
Scoped this fix to this test file only rather than touching test_shared's
shared implementation, which every other module's tests also depend on.
JUnit4's BlockJUnit4ClassRunner requires @Test methods to compile with a
void return type. 'fun test() = runBlocking { ... }' infers the function's
return type from the block's last expression - two of these tests ended
on a Mockito verify(...).someMethod(...) call, whose return type leaks
through as the inferred type (e.g. String, since TronGridApi.broadcastTransaction
returns String) instead of Unit, so the whole test class failed
ParentRunner validation before any test could even run. Declaring the
return type explicitly as Unit makes Kotlin discard the expression's
value (unit-coercion) rather than infer it - added to all three tests for
consistency, not just the two that were actually failing.
Default Gradle test logging only prints the exception class name + one
stack frame for a failing test, not its message or cause chain - that's
exactly what happened debugging RealTronTransactionServiceTest's
InvalidTestClassError just now (console showed nothing beyond the bare
exception type). Not useful for anyone hitting a real test failure in CI
without a local Gradle run to inspect the HTML report.
RealTronTransactionServiceTest needed test-shared's Mockito helpers
(whenever/eq/any/argThat), but feature-wallet-impl never declared
testImplementation project(':test-shared') - every other module that uses
these helpers (feature-account-impl, runtime, common, etc.) already does.
Also pin two ambiguous-without-it type inferences (argThat's lambda param,
emptyMap's type args) explicitly rather than relying on the dependency fix
alone to un-cascade them.
RealTronTransactionService's native-TRX branch (transact/calculateFee for
TronTransactionIntent.Native) had zero automated coverage - only the TRC20
ABI encoding (Trc20TransferAbiTest) and address derivation/formatting
(TronDerivationTest, TronAddressTest) were tested. Send/transfer code
moving real funds shouldn't ship untested just because it happens to share
its sign/broadcast plumbing with an already-tested asset type.
Covers: the raw_data is hashed and signed exactly as documented (sha256,
not the raw bytes or txID), the r+s+v signature is assembled correctly
before being sent to broadcastTransaction, and - the one true security
invariant here - a TronGrid response whose txID doesn't match
sha256(raw_data) is refused before ever reaching the signer, not just
before broadcast. Also covers the native fee estimator's bandwidth-shortfall
math against the documented fallback price.
Fixture note: the raw_data_hex/txID pair here is self-consistent (computed
locally) rather than live-captured against TronGrid, unlike
Trc20TransferAbiTest's ABI vector - this class never encodes a real
TransferContract protobuf itself (see its own class doc), so what matters
is that this service correctly hashes/signs/forwards whatever raw_data
TronGrid returns, which a self-consistent fixture exercises identically.
New order per product spec: Pezkuwi ecosystem, DOT, KSM, USDC, TRX, BTC,
ETH, BNB, AVAX, LINK, TAO, then everything else alphabetically. UNI no
longer gets an explicit slot - it now falls into the same alphabetical
bucket as any other unlisted symbol.
main's scheduled run has been failing most cycles since 2026-07-06 with
either a corrupted SDK package download (Error on ZipFile unknown archive)
or a plain emulator boot timeout - both manifest as adb never reaching
emulator-5554. The job never cached the AVD, so every single run re-hit
Google's SDK servers for a fresh system image download, keeping it exposed
to this exact flake on every run and every 8-hour schedule tick.
Cache the AVD (skips the download entirely once warm) and duplicate the
test-run step as a same-job retry for the residual flake (cold cache, or
a rare boot timeout even with a warm cache).
Adds a real EVM address for the Founder account - derived via standard
BIP44 (m/44'/60'/0'/0/0) from the same already-verified mnemonic used
for the substrate address, since no dedicated founder EVM wallet record
exists anywhere. Ethereum's USDT-ERC20 assetId isn't a fixed integer
like Substrate assets (EvmAssetsSyncService hashes the contract address
at sync time), so it's resolved dynamically via ChainAssetDao instead
of hardcoded in the JSON fixture.
This closes the loop on all 3 originally-reported symptoms from this
investigation: Tron disabled (fixed, unaffected by any revert), Pezkuwi
tokens missing (fixed - ordering bug), USDT on Polkadot AH/Ethereum
missing (Polkadot AH already covered, Ethereum added here). Ethereum
ERC20 sync uses an entirely separate mechanism (EthereumRequestsAggregator,
not Substrate's StorageSubscriptionMultiplexer) so it was likely never
actually broken by anything this session touched - this verifies that
directly instead of assuming it from code reading.
Public TronGrid rate-limits aggressively, and this test now runs on
every PR (plus its own 8h schedule) - a bare 429 was failing runs for
a transient, infrastructure reason unrelated to code correctness. Add
exponential backoff retry instead of treating it as an accepted flake.
Also required-status-check balances_test.yml's run-tests job on main
now that both this and the wallet-utils phantom-asset fix are confirmed
clean - it was deliberately left optional until proven, per "don't
promise gates you haven't verified."
Diffed the whole branch against main (the live, working Play Store
source) instead of continuing to guess from logs. Found the actual
regression: syncAsset() was changed from a suspend fun that EAGERLY
calls startSyncingBalance() (registering each asset's storage key
synchronously, during listenForUpdates()) into a plain fun returning a
lazy flow { } that only calls startSyncingBalance() once collected -
to support a retryWhen wrapper added earlier this session.
BalancesUpdateSystem.launchChainUpdaters() calls
subscriptionBuilder.subscribe(coroutineContext) - which seals the
shared per-chain subscription multiplexer - immediately after
listenForUpdates() returns, then only starts collecting the merged
result flow (which is what triggers the lazy startSyncingBalance()
calls) afterward. So every asset's key registration now races against
the seal instead of reliably happening before it, matching main's
original guaranteed ordering. Some assets win the race often enough to
look like they work; this is why the full ecosystem test - which
creates one account and races ALL of it at once - saw every asset fail,
while the older single-asset test mostly saw only HEZ fail.
Reverted to main's version: suspend syncAsset(), eager
startSyncingBalance() call, no retryWhen. Loses automatic retry of
transient full-sync failures (which the retryWhen wrapper was meant to
add), but that capability isn't worth reintroducing an ordering bug
that can silently break sync for an unpredictable subset of assets on
every chain, not just Pezkuwi's.
CI proved the typed remoteStorage.subscribe DSL swap (previous commit)
was not a fix - it was a regression. All 8 assets across all 3 Pezkuwi
chains failed to sync in the follow-up test run (vs just HEZ-on-Asset-Hub
before), and the logs showed what looks like storage keys meant for
Pezkuwi Asset Hub's Assets pallet being sent to the Pezkuwi relay chain's
connection instead - some kind of cross-chain contamination introduced
by the DSL's interaction with the shared connection, not understood yet.
Reverting to the raw subscriptionBuilder.subscribe(key) form restores
the prior, narrower state: 5 of 6 assets on Pezkuwi Asset Hub sync fine,
HEZ specifically does not, and every other chain is unaffected. The
underlying HEZ bug is still open - this just stops the attempted fix
from actively making things worse while it's investigated further.
removeAll { assetDao.getAsset(...) } failed to compile ("Suspension
functions can only be called within coroutine body"). filter{} is
unambiguously inline and safe for a suspend call inside a suspend
function; pair it with the plain Collection-based removeAll(elements)
overload instead, which takes no lambda at all.
This is what would have caught the 2026-07-09 HEZ-on-Asset-Hub silent sync
regression at PR time instead of hours into a live-app investigation after
merge. Not yet wired as a required status check - want to confirm it runs
clean on real PRs first (TronBalancesIntegrationTest has a known TronGrid
rate-limit flake that would need addressing before this can safely block
merges).
Was HEZ-on-Asset-Hub-only. Now data-driven from wallet-utils' new
pezkuwi_assets_for_testBalance.json (TEST_ASSETS_URL), asserting every
asset - HEZ/PEZ/USDT/DOT/ETH/BTC across Pezkuwi's 3 chains - gets an
assets DB row written via a single shared BalancesUpdateSystem run, not
just one asset on one chain. Failure message lists exactly which assets
never synced, by name and chain.
Root cause found via 4 rounds of CI diagnostics: HEZ (native asset) on
Pezkuwi Asset Hub was correctly present+enabled in the Chain domain model,
correctly dispatched to NativeAssetBalance, and its System.Account storage
key was correctly computed - but the raw subscriptionBuilder.subscribe(key)
call never actually reached the RPC connection, with zero exceptions and
zero data, while the chain's 5 other assets (all statemine-type, all using
the same SharedRequestsBuilder) synced fine. The same NativeAssetBalance
code worked correctly for every OTHER native asset on every OTHER chain
tested, ruling out a generic bug in the class.
Switched startSyncingBalance() to the typed remoteStorage.subscribe { }
DSL (metadata.system.account.observeWithRaw) - the same mechanism this
class's own subscribeAccountBalanceUpdatePoint() and PooledBalanceUpdater/
BalanceLocksUpdater already use successfully on the same busy chain
connection, instead of the raw subscriptionBuilder.subscribe(key) call
that appears to silently drop registration in that specific configuration.
Also removes the diagnostic logging added during the investigation
(BalancesUpdateSystem's per-chain balancesSync trace, FullSyncPaymentUpdater's
per-chain asset dump) - kept the one genuinely valuable permanent addition,
the "listenForUpdates() threw synchronously" error log for a previously
silent failure mode.
Confirmed via 3 CI runs: HEZ (native asset) is present+enabled in the runtime
Chain object for Pezkuwi Asset Hub and gets dispatched to NativeAssetBalance
without any exception, yet its System.Account subscribe request never reaches
that chain's RPC connection at all - no error logged either. This traces
exactly how far execution gets: does startSyncingBalance() even get entered,
does getRuntime()/storageKey() complete, does subscribe()'s flow ever emit.
HEZ (native type, assetId 0) on Pezkuwi Asset Hub never gets a System.Account
subscription sent to the RPC at all - no exception, no log, while the other 5
statemine-type assets on the same chain sync correctly. Ruled out via code
reading: enabledAssets() default, AssetSourceRegistry dispatch, type mapping,
Room composite PK. This logs the actual chain.assets contents at the exact
point enabledAssets() is consumed, to see directly whether HEZ is present/
enabled in the runtime Chain object or silently absent before this point.
First run of this test produced zero BalancesDiag output at all - not even a
single balancesSync() call for any chain. Root cause: BalancesUpdateSystem.start()
is a cold flow only ever collected by RootInteractor, which is wired to the root
Activity/ViewModel lifecycle. This bare instrumented test never launches that
Activity, so the pipeline was never started - the test's own timeout, not the
production bug, explained the failure. Now collect the same AssetsFeatureApi.
updateSystem instance directly instead of relying on app UI lifecycle.
TronBalancesIntegrationTest.kt uses ScalarsConverterFactory but nothing in
app/build.gradle declared it, so the app module's androidTest compilation
failed with "Unresolved reference 'scalars'" - this was never caught before
now because the emulator balances_test.yml workflow only runs on a schedule/
manual dispatch, not on every push.
Hardcoded -e class only ran one test class, silently excluding any new
integration test added to the same package (e.g. the new full-architecture
BalancesUpdateSystem test).
BalancesUpdateSystem.launchChainUpdaters() wrapped updater.listenForUpdates() in a
try/catch that discarded synchronous exceptions with zero logging - a silent failure
point that could explain a chain's balances never syncing with no trace in logcat.
Also add a full-architecture instrumented test that persists a real watch-only
MetaAccount and polls AssetDao through the actual BalancesUpdateSystem pipeline,
instead of bypassing it like the existing BalancesIntegrationTest does.
SELECT * FROM chains had no ORDER BY - SQLite gives no ordering guarantee
for that, so registration/connection order across ~98 chains was
effectively unpredictable per run. The merged chains.json lists Pezkuwi's
own chains first (wallet-utils' merge_chains()), and CollectionDiffer's
findDiff()/Room's batch insert both preserve that order on first sync, so
ordering by rowid (insertion order) makes Pezkuwi's own chains reliably
register and start connecting first/early, instead of being interleaved
unpredictably among ~90+ Nova-inherited chains where they could end up
processed dead last - observed directly: a fresh install took 45+ seconds
without a single Pezkuwi-related registration/connection attempt.
No user should wait minutes for their own wallet's native chain to even
start syncing after install, regardless of whether the eventual outcome
is correct.
Tron is a REST API (TronGrid), not a Substrate runtime, so it never goes
through BalancesIntegrationTest's chainRegistry-based mechanism at all -
it had zero CI coverage. This exercises the exact TronGridApi the
production app uses for balance reads, via a standalone Retrofit client
(TronGridApi isn't exposed through a public feature API for tests to
reach through the DI graph).
Test account is the mainnet Founder's Tron address, verified live via
TronGrid's public API on 2026-07-09: 3,925.23 TRX native + 625,213.92
USDT-TRC20 - substantial real balances, not a guessed or empty account.
mapChainLocalToChain() runs as a single mapList{} transform over the entire
chain list. If it throws for even one malformed row (e.g. a JSON parse
failure on the chain's `additional` blob), the whole transform throws,
killing the Eagerly-shared currentChains/chainsById flows for every chain -
permanently, since Eagerly sharing never restarts once its upstream dies.
This is the same class of bug already fixed for registerChain/unregisterChain
in the diff-processing step below, but one level upstream of it: a mapping
failure here never even reaches that per-chain isolation, since it happens
before the diff is computed at all.
Device logs on a fresh install showed exactly this shape: 8 chains (including
Pezkuwi, Pezkuwi Asset Hub, Polkadot Asset Hub) successfully completed
"Constructed runtime" within the first ~2.5 seconds, then all activity for
every remaining chain stopped completely for the rest of the session - no
crash, no battery-saver kill (confirmed off), the process simply went silent,
consistent with the shared flow dying mid-registration and never recovering.
ChainSyncService.syncUp() and EvmAssetsSyncService.syncEVMAssets() both
diff a freshly-fetched remote list against everything currently stored
locally, then apply that diff unconditionally. If the remote fetch
succeeds but returns a suspiciously small or empty list (CDN hiccup,
regional network filtering, a bad publish upstream) - rather than
throwing, which retryUntilDone would catch and retry - the diff would
delete most or all of the user's chains/assets from the local DB. This
is active data loss, not a sync failure, and it self-heals on the next
good sync if we just skip applying a suspicious one instead.
Directly relevant: a user's live production install (unrelated to any
in-flight branch work) was observed with a completely empty networks
and token list after previously working fine, matching this exact
failure mode.
StatemineAssetBalance and NativeAssetBalance's startSyncingBalance()
wrapped setup and subscription failures in runCatching{}/catch{} that
returned emptyFlow()/NoCause instead of propagating. This meant
FullSyncPaymentUpdater's retryWhen (added for the Tron fix) never
actually engaged for these asset types - a transient failure silently
and permanently stopped sync for that asset (HEZ, PEZ, USDT, DOT, ...)
with only a logcat line as evidence. Let the exceptions propagate so
the existing retry boundary can do its job.
ChainRegistry.currentChains ran registerChain()/unregisterChain() per
chain, unguarded, inside a plain (non-Supervisor) CoroutineScope and an
Eagerly-shared flow that never restarts once it dies. One bad chain row
could permanently kill sync for every chain. Isolated each chain's
register/unregister in its own runCatching, and switched the scope to
a SupervisorJob as defense in depth.
ChainUpdaterGroupUpdateSystem.runUpdaters() called getRuntime() and
built per-chain updater flows with no error boundary; callers merge
several chains' results together, so one chain's failure (e.g. a
disabled chain throwing DisabledChainException) could kill
governance/staking/crowdloan sync for every other chain in the group.
Wrapped the body in flow{} + catch to isolate failures per chain.
Generalizes today's Tron balance-polling fix - the same silent-death
bug exists in the shared Substrate sync path used by every chain
(Interlay, Kintsugi, Karura, Acala, Hydration, Polkadex, and any other
orml/statemine asset), not just Tron-specific code.
FullSyncPaymentUpdater.syncAsset() previously used runCatching around
the one-time startSyncingBalance() call and a separate .catch on the
resulting flow - either path failing (a transient WSS hiccup during
setup, an orml currencyId-decode edge case, a node not supporting a
specific RPC method during round-robin, a dropped connection later)
permanently ended that asset's sync for the Updater's lifetime: no
retry, only a Log.e line, and mapNotNull silently dropped the null
result. Since no balance update flow ever emits, AssetCache never
creates a DB row for that asset, and every UI surface (main list,
multi-chain picker) reads via an INNER JOIN that requires that row -
so the asset stays invisible with zero user-visible error until app
restart, which has the same odds of failing again.
Live-tested: Interlay/Kintsugi's node URLs are all reachable (manual
WSS handshake test, 101 Switching Protocols), and none of these chains
are blacklisted - so this wasn't a connectivity or config issue, it
was this retry gap.
Wraps both the initial subscription call and the ongoing flow in one
flow{} builder with retryWhen (30s fixed interval, matching Tron's
polling interval) instead of runCatching + .catch, so a transient
failure at either point just gets retried instead of permanently
killing sync for that asset.
Real user on a fresh install reported TRX and USDT-TRC20 never
appearing anywhere in the Tokens list (not "zero balance", genuinely
absent - including from the multi-chain USDT chain picker). Traced
the full pipeline; every layer up to and including
TypeBasedAssetSourceRegistry, ChainRegistry, address derivation, and
TronGridApi wiring was already correct.
Root cause: pollingBalanceFlow() had no retry around fetch() - any
single transient failure (DNS hiccup, timeout, momentary connectivity
loss during app cold start) threw out of the `while(true)` loop,
killing the flow permanently. The collector
(FullSyncPaymentUpdater.syncAsset()) only logs and gives up on
failure, it doesn't resubscribe. Since the asset's first balance
write never happens, AssetCache never inserts a DB row for it, and
every UI surface (main list, multi-chain picker, search) reads
exclusively via an INNER JOIN that requires that row to exist - so
the asset is invisible everywhere, permanently, with zero
user-visible error.
Swallow fetch() failures and retry on the next interval instead of
letting them escape the loop - one bad poll no longer blackholes the
asset for the rest of the app session.
Also fixes a related but separate gap found while tracing this:
RealSecretsMetaAccount.multiChainEncryptionIn() had no isTronBased
branch (only isEthereumBased), unlike DefaultMetaAccount's
hasAccountIn/accountIdIn which already handle Tron correctly. This
didn't cause the missing-tokens bug, but would have broken "export
account" (JSON key backup) for Tron - fixed by routing Tron through
MultiChainEncryption.Ethereum, matching what
RealTronTransactionService already does for actual transaction
signing (same secp256k1 keypair).
master was confirmed unused before deletion: no webhook/deploy-key
writes to it, no branch protection, last commit 2026-03-10 (4 months
stale), and no open PR targeted it. Its content was already fully
contained in main's history (main had since diverged far ahead with
v1.0.2/v1.0.3 releases), so nothing was lost.
These four workflows existed solely to serve or react to that branch
and can never trigger again now that it's gone:
- auto-pr.yml / auto-merge.yml: the master->main sync mechanism
itself - its entire purpose is gone along with master.
- pr_workflow.yml: triggers on `pull_request: branches: [master]`
(rc/hotfix release-notes automation) - can't fire, no PRs target
master anymore.
- update_tag.yml: triggers on `push: branches: ['master']` (auto
version tagging) - can't fire either.
The last two encode logic (release-notes extraction, auto-tagging)
that might still be wanted against main - left that as a separate
decision rather than silently re-pointing them, since that would
activate new automation behavior nobody asked for here.
Deliberately not touching .github/workflows/appium-mobile-tests.yml's
`ref: 'master'` - that's a workflow_dispatch call into a *different*
repository (pezkuwichain/appium-mobile-tests) and has nothing to do
with this repo's now-deleted branch.
Real user reported Tron stuck showing "Connecting..." forever in the
Networks screen after the ChainRegistry fix (which correctly skips
creating a ChainConnection for Tron, since TronGrid is a plain REST
API, not WSS). NetworkListAdapterItemFactory.getConnectingState()
rendered every non-Connected state (including the Disconnected
default a missing connection pool entry falls back to) as
"Connecting" with an indefinite shimmer - there was no way to
distinguish "never had a connection to begin with" from "still
negotiating one".
Tron doesn't have a meaningful WS connection state at all (its actual
balance/transfer operations poll TronGridApi directly, confirmed
independent of ChainConnection), so there's nothing correct to show
here - treat it the same as the already-existing isDisabled early
return (no status badge) rather than defaulting into the generic
"still connecting" UI.
Card now opens in a slim single-line pill showing only Trust Score.
Tapping it expands to the full card (citizen status, world Kurdish
count, referral actions); a chevron in the expanded header collapses
it back. Expand state persists across scroll/recycling within the
session but resets to collapsed on a fresh app launch.
main now has the fix for a serious bug that also affects this branch:
ChainRegistry unconditionally attempted a WSS connection for every
chain including Tron (whose node is a plain REST API, not WSS),
hanging indefinitely and blocking all subsequent chain registration
in the sequential registration loop - a real freeze risk for any user
with the Tron chain enabled, found while diagnosing balances_test.yml.
Also pulls in the various CI-only fixes from PR #11 (unrelated to
app behavior).
* fix: use arm64-v8a emulator image on macos-14 runners
The "Run balances tests" job has been failing on every scheduled run
for weeks: the emulator requested an x86 system image while
macos-14 GitHub-hosted runners are Apple Silicon (aarch64) - QEMU2
refuses to boot a mismatched-architecture image ("Avd's CPU
Architecture 'x86' is not supported by the QEMU2 emulator on
aarch64 host"), so every adb command against the never-booted
emulator failed with "device not found" for the full 10-minute
boot timeout on every run.
* fix(ci): run balances-test emulator on ubuntu-latest with KVM instead of macos-14
macos-14 (Apple Silicon) GitHub-hosted runners don't expose nested
virtualization to guests, so the Android emulator's HVF backend fails
with HV_UNSUPPORTED and the job times out waiting for boot - this
affects both x86 and arm64-v8a system images, so the arch: arm64-v8a
change alone wasn't sufficient. macos-13 (which previously supported
this via HAXM) was retired by GitHub.
Linux hosted runners support KVM-accelerated emulators once the kvm
device's udev permissions are relaxed, which is the documented setup
for reactivecircus/android-emulator-runner and also faster/cheaper
than macOS runners.
* fix(ci): build instrumentialTest androidTest APK to match AllureAndroidJUnitRunner
run_balances_test.sh has always targeted
io.novafoundation.nova.debug.test/io.qameta.allure.android.runners.AllureAndroidJUnitRunner,
but android_build.yml's "Build debug tests" step built the plain
debug variant's androidTest APK, whose manifest declares the module
default runner (androidx.test.runner.AndroidJUnitRunner, from
allmodules.gradle) - AllureAndroidJUnitRunner is only wired via
testInstrumentationRunner on the dedicated instrumentialTest build
type (app/build.gradle), which was apparently created for exactly
this purpose but never actually wired into CI. Result:
INSTRUMENTATION_FAILED as soon as the emulator boot issue was fixed
and this step was reached for the first time.
instrumentialTest initWith buildTypes.debug (same applicationIdSuffix
'.debug', same default debug signing), so it installs under the same
package next to the already-built debug app APK - only the
androidTest APK's build type needs to change, not the main app build.
Only balances_test.yml sets build-debug-tests: true, so this doesn't
affect any other android_build.yml caller (pull_request.yml has it
explicitly disabled with its own separate pre-existing TODO).
* test: temporarily point android_build.yml ref at this branch for verification
TEMPORARY - reusable workflow calls (uses: ...@ref) pin to that ref's
copy regardless of the caller's branch, so android_build.yml's fix
never actually ran in the previous verification attempts even though
it was committed to this branch. Must revert to @main before merging
this PR, once android_build.yml's changes are on main.
* fix(ci): declare AllureAndroidJUnitRunner on debug build type, not instrumentialTest
AGP only ever compiles one androidTest APK per module, tied to
android.testBuildType (default "debug", never overridden in this
project) - so a testInstrumentationRunner override on any other build
type, including instrumentialTest, is unreachable regardless of which
gradle task or main-app variant is used. That's why the previous
attempt (assembleInstrumentialTestAndroidTest) failed outright: no
such task exists, since androidTest is only ever generated for
testBuildType.
Reverts the previous commit's task/path changes back to
assembleDebugAndroidTest / app/androidTest/debug/..., and instead
moves the testInstrumentationRunner override onto the debug build
type itself, which is what androidTest actually compiles against and
what run_balances_test.sh has always targeted. Also drops the dead
override from instrumentialTest now that it's confirmed non-functional
there.
* debug(ci): dump pm list instrumentation before running balances test
Diagnostic only - the previous fix (testInstrumentationRunner moved
to the debug build type's defaultConfig) still hit the identical
INSTRUMENTATION_FAILED for AllureAndroidJUnitRunner even though both
APKs now install successfully with the corrected paths. Need to see
what PackageManager actually registered for the installed test APK
rather than keep guessing from Gradle DSL evaluation-order theory -
allmodules.gradle's subprojects{} block also sets
testInstrumentationRunner on every module including app, and it's not
yet confirmed which assignment wins.
* fix(ci): use current io.pezkuwichain.wallet package instead of stale upstream name
Diagnostic (pm list instrumentation) confirmed the real, final root
cause: AllureAndroidJUnitRunner IS correctly registered on-device
after the previous fix, but under the app's real applicationId
(io.pezkuwichain.wallet, set in build.gradle since the Pezkuwi rebrand)
- not the pre-rebrand upstream Nova Wallet package
(io.novafoundation.nova) these scripts still hardcoded. Every previous
INSTRUMENTATION_FAILED was simply am instrument targeting a package
that was never installed.
Also fixes the identical stale reference in run_instrumental_tests.sh
(currently unused by any workflow, but has the same bug).
The BalancesIntegrationTest class's own Kotlin package
(io.novafoundation.nova.balances) is untouched - that's the test
class's real source package on disk, unrelated to the app's
applicationId, and was never part of the bug.
* fix(ci): bound run-tests to 25min and unbuffer python output
Latest verification run hung for 1h15m+ inside am instrument with
zero visible progress - had to be cancelled manually. Post-mortem:
Python's stdout is fully buffered (not line-buffered) when piped
under GitHub Actions' `run:`, so the script's own 5s heartbeat prints
(explicitly there to avoid CI's inactivity-based cancellation) never
actually reached the log until the buffer filled near the very end,
making the run look identical to a genuine hang for its entire
duration with no way to tell what BalancesIntegrationTest was doing.
- timeout-minutes: 25 on run-tests bounds any future hang to a fixed,
reasonable ceiling instead of requiring a manual cancel after an
hour+.
- python -u unbuffers stdout so the next run's logs show real-time
heartbeat/output, giving actual visibility into where a hang (or
slow chain RPC) occurs instead of a silent multi-hour gap.
Root cause of the hang itself is still open - this only makes it
diagnosable and bounds its cost.
* fix: skip WSS ChainConnection setup for Tron-based chains
Real root cause of the 1h15m+ hang in the previous verification run
(had to be cancelled manually): ChainRegistry registers all chains
sequentially (diff.newOrUpdated.forEach { registerChain(it) }), and
registerConnection() unconditionally called
connectionPool.setupConnection(chain), which creates a ChainConnection
backed by a WSS-only SocketService - for every chain, with no check
for chain type. Tron's node (https://api.trongrid.io) is a plain REST
API with no WebSocket support, so this connection attempt just hangs
forever with no timeout, and since registration is sequential and
Pezkuwi chains (including Tron) are ordered first in the merged chain
list, every chain after it in the list never finishes registering
either - including all the third-party chains BalancesIntegrationTest
actually exercises.
This isn't just a test problem: any real user with the Tron chain
enabled would hit the same registry-wide freeze during chain sync.
Tron balance/transfer operations already go through their own
TronGridApi REST client (built in the Phase 1/2 Tron work),
independent of ConnectionPool/ChainConnection - confirmed nothing else
reads chainRegistry.getConnection() for a Tron chain id - so skipping
ChainConnection setup entirely for isTronBased chains is safe.
* debug(ci): stream live logcat during test run
Diagnostic only. Previous fix (skip WSS ChainConnection for
isTronBased chains) did NOT resolve the hang - identical symptom
(silent for the full 25min timeout, just heartbeats, nothing from the
actual test process). Need real device-side visibility into what's
actually happening (network calls, coroutine timeouts, ANRs) instead
of guessing blind from am instrument's own stdout/stderr, which stays
completely silent until the process exits.
* debug(ci): SIGQUIT thread dump 3min into a hung run, bump logcat to debug level
Previous diagnostic (live logcat at info level) showed the app staying
genuinely alive (GC cycles, system chatter) but produced zero signal
from the test itself after the initial successful chains.json fetch -
no WSS/DB/coroutine activity visible, likely because relevant logging
is below info level. Static code reading (ChainConnection.setup(),
ChainSyncService.syncUp(), ChainFetcher) hasn't turned up an obvious
blocking call, and this exact hang predates this session by at least
a month (zero successes in the last 100 scheduled runs going back to
2026-06-09) - so it's a real, previously-latent bug in the app/test
itself, never previously reached because every earlier run failed at
an earlier CI-infra stage.
kill -3 on the app process forces ART to dump every thread's Java
stack trace to logcat (the standard ANR-diagnosis technique) - this
should show exactly which coroutine/thread is parked and where,
instead of continuing to guess from log filtering.
* fix(ci): bump run-tests timeout to 90min, drop now-unneeded SIGQUIT diagnostic
With the chain blacklist fixed, the previous run genuinely started
executing the 160-case parameterized test suite (visible TestRunner
started/finished events for real chains) instead of hanging silently
- first time this has happened in this entire investigation.
It still hit the 25min ceiling: each test case has an explicit
withTimeout(80.seconds), and several chains that aren't fully dead
(so not blacklisted) but are slow/unresponsive burn the full 80s
before failing. With 160 total test cases, the worst-case aggregate
easily exceeds 25 minutes even with zero actual hangs - so the
timeout needs to be realistic for the test's own design, not just
long enough to catch a true infinite hang. 90min matches
android_build.yml's existing precedent for this project's CI jobs.
The SIGQUIT-after-3-minutes diagnostic added earlier is now
counterproductive noise: any healthy run legitimately takes far
longer than 3 minutes to get through 160 cases, so it would fire on
every run rather than only genuine hangs. Removed now that its actual
purpose (finding the real hang) is done - the blacklist was the
answer, not something a thread dump would have caught anyway (dead
sockets, not deadlocked application code).
* chore: revert temporary android_build.yml ref pin back to @main
Was pointed at this branch only to verify android_build.yml's own
fixes actually took effect during iteration (reusable workflow calls
resolve against the ref they're pinned to, not the caller's branch).
android_build.yml is now byte-identical to main (the wrong task-name
attempt was fully reverted in an earlier commit), so this is a no-op
functionally - just restoring the correct long-term reference before
merge.
pull_request-triggered runs of this workflow have stopped firing
entirely for at least one recent PR (no check-suite created at all
for the GitHub Actions app, while two other installed apps sit stuck
in "queued") - root cause is outside what's fixable via the repo's
own Actions config/API access. This adds a manual workflow_dispatch
path (branch input) so a build+test run can still be triggered
directly against any branch while that's being sorted out.
