[Bug]: Network status icon keeps showing sync issues

[pwltr]

What happened?

It keeps showing UI for network connection issues for me, yellow sync icon pops up repeatedly. Not sure if there is actually any problems or just UI.

Additional Context

• I did not allow the app to run in background
• It is the same with and without connecting over VPN, otherwise stable WiFi

screen-20260326-120125-1774522804808.mp4

bitkit_2026-03-26_11-16-44.log

Bitkit Version

2.1.2

Device / OS

Pixel 8

Reproducibility

Always

[ovitrif]

Investigate: Android network connection status icon flashing

GitHub issue: #869
Reported by: Philipp (Pixel 8, v2.1.2)
Symptom: Yellow sync icon flashes repeatedly. Not a real network issue - stable WiFi, same with/without VPN. Fixed by reinstall but NOT by wallet wipe.

Root Cause

A migration retry loop causes repeated sync cycles (~every 10s), each briefly setting isSyncingWallet = true, which flashes the yellow icon.

Why it loops:

1. WipeWalletUseCase doesn't clear rnMigrationDataStore - old migration data (34 Blocktank order IDs, 2 paid orders) survives wallet wipe
2. MigrationService.reapplyMetadataAfterSync() tries to fetch old orders from Blocktank API
3. API fails because the qs query parser has arrayLimit: 20 - with 34 IDs, the array becomes an object, Zod rejects it
4. canCleanupAfterMigration returns false → "Post-migration sync incomplete, will retry on next sync"
5. Next SyncCompleted event → AppViewModel.handleSyncCompleted() → completeMigration() → loop

Relevant log lines (bitkit_2026-03-26_11-16-44.log)

Line 23:  ERROR [ActivityRepo.kt:101]    Failed to sync activities [...node is 'Stopped'...]
Line 395: WARN  [MigrationService.kt:1755] Still unable to fetch Blocktank orders [...ZodError...Expected array, received object...]
Line 396: DEBUG [MigrationService.kt:318]  Cannot cleanup: pending Blocktank data exists
Line 397: INFO  [AppViewModel.kt:527]      Post-migration sync incomplete, will retry on next sync
          (repeats at lines 636, 860, 1092 — every ~10 seconds)

---

Fix 1: Clear migration store on wallet wipe

File: app/src/main/java/to/bitkit/usecases/WipeWalletUseCase.kt

Currently calls migrationService.markMigrationChecked() but never clears pending migration data. After a wallet wipe, the old wallet's keys are destroyed so pending orders can never be completed anyway.

Changes:

1. Add a resetAllMigrationData() method to MigrationService that clears the rnMigrationDataStore and nulls out all in-memory pending fields:

   • pendingBlocktankOrderIds = null
   • pendingRemotePaidOrders = null
   • pendingRemoteMetadata = null
   • pendingRemoteTransfers = null
   • pendingRemoteBoosts = null
   • Clear the DataStore: rnMigrationStore.edit { it.clear() }

2. In WipeWalletUseCase, call migrationService.resetAllMigrationData() instead of (or in addition to) migrationService.markMigrationChecked().

Key code locations in MigrationService.kt:

• loadPersistedMigrationData() (~line 172) - loads pending data from DataStore on startup
• clearPersistedBlocktankData() (~line 265) - existing method that clears just Blocktank data; extend pattern to clear ALL migration data
• canCleanupAfterMigration (~line 315) - the gate that blocks cleanup
• needsPostMigrationSync() (~line 156) - checks RN_NEEDS_POST_MIGRATION_SYNC_KEY

Important: Don't break the legitimate RN→native migration flow. The pending orders flow is critical: start order in RN → migrate → native app fetches orders, creates transfers, opens channels. Only clear on explicit wallet WIPE (keys are gone anyway).

Fix 2: Increase qs arrayLimit on Blocktank server

Repo: blocktank-lsp-http
File: service/src/3_api/createApp.ts

The qs library defaults to arrayLimit: 20. With >20 query params using bracket notation (ids[]=), items above index 20 become object properties. Zod's z.array() then rejects it.

Change: Configure Express query parser:

import qs from 'qs';
app.set('query parser', (str: string) => qs.parse(str, { arrayLimit: 100 }));

The endpoint already validates max(50) via Zod, so 100 gives headroom.

Alternative (no server change): Client-side batching in MigrationService.reapplyMetadataAfterSync() (~line 1731) - split order IDs into batches of 20 and make multiple coreService.blocktank.orders() calls. This is a good idea regardless as a defensive measure.

Fix 3: Client-side batching as defensive measure

File: app/src/main/java/to/bitkit/services/MigrationService.kt
Location: reapplyMetadataAfterSync() (~line 1731)

Currently sends all pending order IDs in one request. Split into batches of <=20:

// Instead of:
val fetchedOrders = coreService.blocktank.orders(orderIds = orderIds, ...)

// Do:
val fetchedOrders = orderIds.chunked(20).flatMap { batch ->
    coreService.blocktank.orders(orderIds = batch, filter = null, refresh = true)
}

This prevents the qs arrayLimit issue regardless of server configuration and handles any number of pending orders.

Code flow reference (for implementation context)

Yellow icon chain:

SyncCompleted event
  → AppViewModel.handleSyncCompleted()    [AppViewModel.kt ~line 440]
  → needsPostMigrationSync() == true      [MigrationService.kt ~line 156]
  → completeMigration()                    [AppViewModel.kt ~line 503]
  → walletRepo.syncNodeAndWallet()         [triggers isSyncingWallet = true]
  → HealthRepo sees PENDING               [HealthRepo.kt ~line 69]
  → AppStatus renders yellow icon          [AppStatus.kt]
  → reapplyMetadataAfterSync() fails       [MigrationService.kt ~line 1674]
  → canCleanupAfterMigration == false      [MigrationService.kt ~line 315]
  → "will retry on next sync"              [AppViewModel.kt ~line 527]
  → next SyncCompleted → loop

Wallet wipe flow:

WipeWalletUseCase:
  backupRepo.reset()
  keychain.wipe()
  coreService.wipeData()
  db.clearAllTables()
  settingsStore.reset()
  cacheStore.reset()
  widgetsStore.reset()
  blocktankRepo.resetState()
  activityRepo.resetState()
  lightningRepo.wipeStorage()
  migrationService.markMigrationChecked()  ← MISSING: rnMigrationDataStore.clear()

Pending orders flow (DO NOT BREAK):

RN app: user starts order, doesn't pay
  → MMKV stores orderId
Migration: loadPersistedMigrationData()
  → pendingBlocktankOrderIds loaded from DataStore
Post-sync: reapplyMetadataAfterSync()
  → coreService.blocktank.orders(orderIds) fetches from server
  → createTransfersForPaidOrders() creates transfer records
  → applyRemotePaidOrders() updates cache
  → BlocktankRepo.openChannelWithPaidOrders() opens channels

Verification

1. Fix 1: Wipe wallet → create new wallet → confirm no migration retry in logs, no yellow icon
2. Fix 2: Send >20 order IDs to GET /channels → confirm parsed as array
3. Fix 3: Test with 25+ pending order IDs → confirm batched fetching works
4. Regression: Test full RN→native migration with pending unpaid order → confirm order is picked up, paid, channel opened