If SQLite clearAll fails mid-panic, in-memory state was already cleared
but a process restart could reload encrypted history from disk (#699).
Fall back to deleting the database files before reporting failure.
A relay that fails is retried on an exponential backoff, then abandoned
for the lifetime of the process. Nothing brings it back: the relay layer
registers no connectivity callback, the periodic subscription validator
only repairs subscriptions on sockets that are already open (and returns
immediately when connectedRelayCount is 0, which is exactly the state
after an outage), and connect() runs once from NostrClient.initialize().
The remaining paths that reset reconnectAttempts are a manual retry, a
Tor state change, and a successful open.
Two ways a relay died permanently:
- Any error whose message mentioned DNS returned before scheduling
anything at all. "Unable to resolve host" is what this device reports
when it simply has no network, so a moment in a tunnel killed every
relay at once, with no retry ever.
- Otherwise the schedule stopped at MAX_RECONNECT_ATTEMPTS. With
INITIAL=1s and MULTIPLIER=2 that is nine waits totalling about eight
and a half minutes, after which the relay was dead. MAX_BACKOFF_INTERVAL
was unreachable: attempt 9 asks for 256s and attempt 10 gave up, so the
five-minute ceiling the constant defines never applied to anything.
Let the backoff saturate at MAX_BACKOFF_INTERVAL and keep retrying there.
A name-resolution failure now backs off like any other error. Steady state
costs one connection attempt per relay per five minutes; the previous
behaviour cost the user every internet DM, delivery receipt and geohash
channel until they noticed and restarted the app.
The schedule moves into RelayReconnectPolicy so it is unit-testable
without OkHttp or a Context.
The class doc described neither what encode writes nor what decode
reads: it claimed 2-byte lengths for every TLV and an 8-byte FILE_SIZE,
where the code uses 4 bytes for both CONTENT and FILE_SIZE, and it
presented multi-TLV chunking as the way large files are carried when v2
writes exactly one CONTENT TLV and fragments at the transport layer.
docs/file_transfer.md already has this right. Bringing the doc on the
type into line with it, and recording why the multi-TLV tolerance path
has to stay linear, since that is what this branch changes.
Pins ordering across chunks, the single-TLV round trip, an empty CONTENT
TLV, rejection when CONTENT is absent, and correct reassembly at 200k
chunks.
Deliberately no wall-clock assertion: a threshold wide enough to be
stable on slow CI is too wide to fail on the quadratic path, so it would
only add flake. The 2435ms/65ms comparison was measured directly and is
in the pull request instead.
