What happened?
ElectrumProbeService produces precise, actionable failure reasons, but ElectrumConfigScreen throws them away and always shows the same generic toast.
The failure branch ignores result.exceptionOrNull() entirely:
// app/src/main/java/to/bitkit/ui/settings/advanced/ElectrumConfigScreen.kt:70-77
} else {
app.toast(
type = Toast.ToastType.WARNING,
title = context.getString(R.string.settings__es__server_error),
description = context.getString(R.string.settings__es__server_error_description),
testTag = "ElectrumErrorToast",
)
}
ElectrumConfigViewModel does carry the real cause through (connectionResult = Result.failure(e)), so the information is available at the UI layer — it is just never read.
Every rejection therefore renders as:
Electrum Connection Failed
Bitkit could not establish a connection to Electrum.
even though ElectrumProbeError already distinguishes four cases, two of which are directly actionable by the user:
| Error |
Message the probe already builds |
NetworkMismatch |
wrong network, with expected vs actual genesis hash |
ProtocolMismatch |
failed TLS handshake, "check the protocol" |
Unreachable |
could not reach the server |
NotElectrum |
host answered, but does not speak Electrum |
The two worth surfacing are NetworkMismatch (user pointed a testnet/regtest wallet at a mainnet server, or vice versa) and ProtocolMismatch (user picked TLS on a plain-TCP port, or the reverse). Today both look identical to "the server is down", so there is nothing to act on.
Expected behavior
The toast should reflect the probe's verdict — at minimum a distinct, localized message for NetworkMismatch and ProtocolMismatch, falling back to the current generic string for Unreachable / NotElectrum / anything unrecognized.
Steps to Reproduce
- Run a non-mainnet build (dev/regtest or tnet).
- Settings → Advanced → Electrum Server.
- Enter
electrum.blockstream.info, port 50002, protocol TLS (a healthy mainnet server).
- Tap Connect To Host.
- A generic "Bitkit could not establish a connection to Electrum." toast appears — despite the connection succeeding and the server being rejected purely for being on the wrong network.
The same generic toast appears for an unreachable host (10.255.255.1:9999) and for a non-Electrum host (tcp://google.com:443).
Logs / Screenshots / Recordings
Verified on-device; the log has the precise reason the user never sees:
11:40:53.705 INFO [LightningRepo.kt:734] Changing ldk-node electrum server to: 'ssl://electrum.blockstream.info:50002'
11:40:55.241 WARN [LightningRepo.kt:737] Rejected electrum server 'ssl://electrum.blockstream.info:50002'
[NetworkMismatch='Rejected electrum server 'ssl://electrum.blockstream.info:50002' on wrong network,
expected '0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206'
got '000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f'']
UI at that moment (via layout dump):
Electrum Connection Failed
Bitkit could not establish a connection to Electrum.
Bitkit Version
2.4.1 (build 188). ElectrumConfigScreen.kt and ElectrumConfigViewModel.kt are byte-identical on master and on release-2.4.1, so this affects both.
Device / OS
Android emulator, sdk_gphone16k_arm64 (16 KB page size), dev/regtest flavor.
Reproducibility
Always
Additional context
- Behaviour is unchanged from before
ElectrumProbeService was introduced — the probe added the good diagnostics, the UI just never started using them. So this is a follow-up to the probe work rather than a regression.
- Nothing is persisted on rejection and the node is correctly never torn down, so the impact is purely that the user cannot tell why their server was refused.
- Scope is small and self-contained: branch on the
ElectrumProbeError subclass in the LaunchedEffect failure branch and add two string resources.
What happened?
ElectrumProbeServiceproduces precise, actionable failure reasons, butElectrumConfigScreenthrows them away and always shows the same generic toast.The failure branch ignores
result.exceptionOrNull()entirely:ElectrumConfigViewModeldoes carry the real cause through (connectionResult = Result.failure(e)), so the information is available at the UI layer — it is just never read.Every rejection therefore renders as:
even though
ElectrumProbeErroralready distinguishes four cases, two of which are directly actionable by the user:NetworkMismatchProtocolMismatchUnreachableNotElectrumThe two worth surfacing are
NetworkMismatch(user pointed a testnet/regtest wallet at a mainnet server, or vice versa) andProtocolMismatch(user picked TLS on a plain-TCP port, or the reverse). Today both look identical to "the server is down", so there is nothing to act on.Expected behavior
The toast should reflect the probe's verdict — at minimum a distinct, localized message for
NetworkMismatchandProtocolMismatch, falling back to the current generic string forUnreachable/NotElectrum/ anything unrecognized.Steps to Reproduce
electrum.blockstream.info, port50002, protocol TLS (a healthy mainnet server).The same generic toast appears for an unreachable host (
10.255.255.1:9999) and for a non-Electrum host (tcp://google.com:443).Logs / Screenshots / Recordings
Verified on-device; the log has the precise reason the user never sees:
UI at that moment (via layout dump):
Bitkit Version
2.4.1 (build 188).
ElectrumConfigScreen.ktandElectrumConfigViewModel.ktare byte-identical onmasterand onrelease-2.4.1, so this affects both.Device / OS
Android emulator,
sdk_gphone16k_arm64(16 KB page size), dev/regtest flavor.Reproducibility
Always
Additional context
ElectrumProbeServicewas introduced — the probe added the good diagnostics, the UI just never started using them. So this is a follow-up to the probe work rather than a regression.ElectrumProbeErrorsubclass in theLaunchedEffectfailure branch and add two string resources.