The package currently waits a hardcoded second for the connection to succeed and when that times out it leaves the connection in an undetermined state. Increasing the timeout could give someone more certainty the connection actually failed.
This might be legacy code considering usage of WithBlock in lightning-node-connect's grpc.DialOptions is listed as a deprecated antipattern.
Anyway, it's hard to determine, as a consumer of connect, how to recover when the function reports a failure.
|
// repeatedly check if the connection was successful |
|
return new Promise<void>((resolve, reject) => { |
|
let counter = 0; |
|
const interval = setInterval(() => { |
|
counter++; |
|
if (this.isConnected) { |
|
clearInterval(interval); |
|
resolve(); |
|
log.info('The WASM client is connected to the server'); |
|
|
|
// clear the in-memory credentials after connecting if the |
|
// credentials are persisted in local storage |
|
if (this.credentials.password) { |
|
this.credentials.clear(true); |
|
} |
|
} else if (counter > 20) { |
|
clearInterval(interval); |
|
reject( |
|
new Error( |
|
'Failed to connect the WASM client to the proxy server' |
|
) |
|
); |
|
} |
|
}, 500); |
|
}); |
The package currently waits a hardcoded second for the connection to succeed and when that times out it leaves the connection in an undetermined state. Increasing the timeout could give someone more certainty the connection actually failed.
This might be legacy code considering usage of
WithBlockinlightning-node-connect'sgrpc.DialOptionsis listed as a deprecated antipattern.Anyway, it's hard to determine, as a consumer of
connect, how to recover when the function reports a failure.lnc-web/lib/lnc.ts
Lines 226 to 250 in f65cf92