On my first node I succesfully synced Electrs Pruned (0.11.1:38) to status “Fully synced”. However, on my second node it reaches 100.0%, but then it never reaches status “Fully synced”. Exact status at time of writing this topic:
Electrs is building its address index: 100.0%, block 970,301 of 970,304. This can take several hours on first run.
When I (stop and) restart the app, it once again syncs up to the latest block, yet it never goes to status “Fully synced”.
Once it finishes indexing, it does several compacting steps (you can see these in the logs). This also takes a couple hours IIRC. If you stop it during a compaction step, that particular compaction has to start over when you start back up again, so this can bite you if you are impatient.
Full SHA256 chain is fully synced; I tried stopping it to see if it made any diff to CPU usage - but the usage remained very low; so started it up again. The only thing I noticed was a bit more heat when running both chains
It should sync faster if the full node is running. It will automatically use the full node if it detects it, up until the chain split, then it will switch to the other node that you have configured in Actions & Config > Select Node (which should be set to your companion node). Try stopping Electrs Pruned, start the full node and wait a minute, then start Electrs Pruned again. It should detect the full node on startup and hopefully sync faster. Syncing from a pruned node is much slower, because it has to reach out to the peers on the network to get each block that has been pruned.
2026-09-09T20:33:59+09:30 [2026-09-09T11:03:59.113Z ERROR electrs::server] 4804: disconnecting due to failed to send response: "{\"error\":{\"code\":-32603,\"message\":\"unavailable index\"},\"id\":1,\"jsonrpc\":\"2.0\"}\n"
2026-09-09T20:33:59+09:30 [2026-09-09T11:03:59.113Z WARN electrs::server] 4804: failed to shutdown TCP connection Transport endpoint is not connected (os error 107)
2026-09-10T10:16:10+09:30 [2026-09-10T00:46:10.597Z WARN electrs::daemon] bitcoind is pruned (pruneheight=960797); blocks below that height will be fetched over RPC rather than p2p
Maybe. I’ll see if I can find where that message gets printed. It might always get printed when connected to a pruned node, even if it has a full node to grab from, but based on your speed you are seeing it probably isn’t doing what it is supposed to. No, don’t stop the companion.