fix(lite): fast retry when a server is only warming up (-28)
When the preferred lightwalletd server is reachable but warming up (JSON-RPC -28 / "Activating best chain"), the failover treated it like a dead server and fell through to the others, so the wallet didn't open until the next 20s retry — even though the healthy server was ready within seconds. Detect the warmup error during failover, flag it on the open outcome (lastOpenWasWarmup()), and have the App retry on a short ~4s interval in that case instead of 20s, so the wallet opens promptly once warmup clears. A unit test covers a warming-preferred + dead-fallback open setting the flag. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
@@ -3599,8 +3599,26 @@ void testLiteWalletControllerOpenFailover()
|
||||
EXPECT_TRUE(!controller.lastOpenError().empty());
|
||||
}
|
||||
|
||||
// A warming-up (-28) server is flagged so the caller can retry sooner. Preferred server is
|
||||
// warming, the fallback is dead -> open fails but lastOpenWasWarmup() is set.
|
||||
{
|
||||
dragonx::test::resetLiteFakeCounters();
|
||||
dragonx::test::g_liteFakeWalletExists = true;
|
||||
dragonx::test::g_liteFakeWarmupServerSubstr = "dead.example"; // preferred (sticky) is warming
|
||||
dragonx::test::g_liteFakeDeadServerSubstr = "good.example"; // fallback unreachable
|
||||
LiteWalletController controller(liteCaps, conn,
|
||||
LiteClientBridge::fromApi(dragonx::test::makeFakeLiteApi()));
|
||||
EXPECT_TRUE(controller.beginOpenExisting());
|
||||
for (int i = 0; i < 400 && controller.openInProgress(); ++i)
|
||||
std::this_thread::sleep_for(std::chrono::milliseconds(5));
|
||||
controller.pumpAsyncOpen();
|
||||
EXPECT_FALSE(controller.walletOpen());
|
||||
EXPECT_TRUE(controller.lastOpenWasWarmup());
|
||||
}
|
||||
|
||||
dragonx::test::g_liteFakeWalletExists = false;
|
||||
dragonx::test::g_liteFakeDeadServerSubstr.clear();
|
||||
dragonx::test::g_liteFakeWarmupServerSubstr.clear();
|
||||
}
|
||||
|
||||
// M2: a parsed lite refresh bundle maps through to the app's WalletState (the last hop
|
||||
|
||||
Reference in New Issue
Block a user