Commit Graph

6 Commits

Author SHA1 Message Date
pezkuwichain 9105560a36 test: verify Ethereum USDT sync too, closing the third originally-reported gap
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.
2026-07-09 19:53:32 -07:00
pezkuwichain 593fedcdd4 fix: avoid suspend call inside non-inline removeAll(predicate)
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.
2026-07-09 12:34:02 -07:00
pezkuwichain 72a881c059 test: expand full-architecture test to cover the whole Pezkuwi ecosystem
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.
2026-07-09 12:08:27 -07:00
pezkuwichain c5174d0ccf fix: NativeAssetBalance uses typed subscribe DSL, not raw key subscription
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.
2026-07-09 11:53:35 -07:00
pezkuwichain 2bb8a4e3d0 fix: actually start BalancesUpdateSystem in the full-architecture test
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.
2026-07-09 09:15:28 -07:00
pezkuwichain 688a23ba6b fix: log and stop swallowing synchronous listenForUpdates() failures; retry NDK download in CI
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.
2026-07-09 07:52:15 -07:00