when trying to diagnose the problem a few days ago I vibed this:
<https://gitworkshop.dev/danconwaydev.com/ngit/tree/timeout-testing/timeout_test>;
what I found was that the connection was failing early (often <500ms but always <1s) whereas nak took a bit longer but succesfully estalished a connection.
sometimes try_connect would return Ok(()) but relay.is_connected() would return false.
When nak couldnt establish a connection try_connect seemed to honour the specified timeout instead of failing quickly.
I ended up building in auto-retry that retires after an ever increasing delay up until the timeout. See src/lib/client.rs line 773-842. What I found with this is it would fail quickly everytime but never, in my limited testing, did it successfully connect on subsiquent attempts.
I was wondering whether try_connect() was picking up some sort of unexpected service respose that nak was ignoring but rust-nostr saw as a failure. I stopped getting the failures before I could dig any deeper and I haven't had any since.
I did all of this on rust-nostr v0.43. The tip of master is now on v0.44 (but i hadn't pushed it when fiatjaf (nprofile…cy6q) last built ngit from master so his failures would be using v0.43)
DanConwayDev
npub15q…cyejr
2025-11-14 23:09:27 UTC
in reply to nevent1q…3waa
Author Public Key
npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejrSeen on
wss://relay.damus.ioPublished at
2025-11-14 23:09:27 UTCEvent JSON
{
"id": "95f7195e09f44d700566e5322fae0e5dfcd87b9e109ea1791161135e22065cef",
"pubkey": "a008def15796fba9a0d6fab04e8fd57089285d9fd505da5a83fe8aad57a3564d",
"created_at": 1763161767,
"kind": 1111,
"tags": [
[
"E",
"29e8643eb9e1680621b2029c08e9a63e5c395a35fee86b8a3fa6fdf74bfaacb7",
"",
"a008def15796fba9a0d6fab04e8fd57089285d9fd505da5a83fe8aad57a3564d"
],
[
"K",
"1621"
],
[
"P",
"a008def15796fba9a0d6fab04e8fd57089285d9fd505da5a83fe8aad57a3564d"
],
[
"k",
"1111"
],
[
"p",
"68d81165918100b7da43fc28f7d1fc12554466e1115886b9e7bb326f65ec4272"
],
[
"e",
"a97cc8077259786b826651f16b222d21cd8f9dd8486c1489d88424c432354684",
"",
"68d81165918100b7da43fc28f7d1fc12554466e1115886b9e7bb326f65ec4272"
],
[
"p",
"a008def15796fba9a0d6fab04e8fd57089285d9fd505da5a83fe8aad57a3564d",
"wss://relay.damus.io/"
],
[
"p",
"3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d",
""
]
],
"content": "when trying to diagnose the problem a few days ago I vibed this:\n\n\u003chttps://gitworkshop.dev/danconwaydev.com/ngit/tree/timeout-testing/timeout_test\u003e\n\nwhat I found was that the connection was failing early (often \u0026lt;500ms but always \u0026lt;1s) whereas nak took a bit longer but succesfully estalished a connection.\n\nsometimes try_connect would return Ok(()) but relay.is_connected() would return false.\n\nWhen nak couldnt establish a connection try_connect seemed to honour the specified timeout instead of failing quickly.\n\nI ended up building in auto-retry that retires after an ever increasing delay up until the timeout. See src/lib/client.rs line 773-842. What I found with this is it would fail quickly everytime but never, in my limited testing, did it successfully connect on subsiquent attempts.\n\nI was wondering whether try_connect() was picking up some sort of unexpected service respose that nak was ignoring but rust-nostr saw as a failure. I stopped getting the failures before I could dig any deeper and I haven't had any since.\n\nI did all of this on rust-nostr v0.43. The tip of master is now on v0.44 (but i hadn't pushed it when nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8g2lcy6q last built ngit from master so his failures would be using v0.43)",
"sig": "ea074ed41cf605cf27028e66e219a8fd74c0dd0e3113450244aac8a1b0e6bd39c87b50092a2d412157dfae741947b3dc942d33989a517411ed5a62d4e1153ca7"
}