Skip to content

Bump lwsf to da8e261: fix wallets bricked past 2048 transactions#6

Open
peachbits wants to merge 1 commit into
mainfrom
matthew/lwsf-2048-fix
Open

Bump lwsf to da8e261: fix wallets bricked past 2048 transactions#6
peachbits wants to merge 1 commit into
mainfrom
matthew/lwsf-2048-fix

Conversation

@peachbits

@peachbits peachbits commented Jul 16, 2026

Copy link
Copy Markdown
Contributor

Description

Bumps the lwsf pin from cedb2164 (Nov 7, 2025) to da8e2617 (Dec 13, 2025) to fix XMR wallets permanently stuck at "synchronizing" with no progress.

Root cause

The old pin parses get_address_txs with wire::max_element_count<config::max_txes_in_rpc> = 2048. Any wallet whose transaction list exceeds that throws during response parsing on every refresh pass, which resets passed_login and restarts the loop: login → get_subaddrs → get_address_txs → parse throw, every ~30 s, forever. The server is healthy the whole time (HTTP 200s), so nothing shows up server-side except the login churn.

Because the tx list includes candidate spends (every ring-decoy reference to the wallet's outputs), it grows monotonically with wallet age — every long-lived wallet eventually crosses 2048 and bricks. Two production support cases confirmed (one wallet at 2,514 txs / 1.4 MB response).

Upstream da8e261 ("Update get_address_txs tx array constraint") replaces the count cap with a min_element_size byte guard.

What's absorbed with the bump (cedb2164..da8e2617)

  • SSL: support for providing a CA file for verification
  • rpc timeout adjustments (adds config::connect_timeout)
  • HTTP path prefixing in the LWS client (invoke_payload gains a prefix param)
  • connect-status fix
  • subaddr lookahead update

Deliberately not HEAD: this avoids the later websocket/boost-beast transition and the newer-monero requirements ("blackball" removal), keeping the hotfix surface minimal. The monero pin is unchanged.

Build-patch changes (scripts/libraries/lwsf.ts)

  • Re-anchored the invoke_payload api_key/Nym patch onto the new upstream text.
  • The Nym branch now runs before the new socket-connect block, so Nym wallets never open a direct TCP connection to the daemon.
  • The patcher now fails the build if the anchors stop matching upstream, instead of silently compiling an unpatched client (no api_key injection → every request 401s).

Verification

  • verify-repo passes (install, prepare, eslint on changed files).
  • Deterministic repro/regression harness (local stub replaying the real 2,514-tx production payload through the compiled lwsf stack via the Node addon target, branch matthew/node-build-target):
served txs old pin (cedb2164) this PR (da8e2617)
2514 (real payload) bricked — never requests get_unspent_outs, synced height 0 parses, refresh proceeds
2049 bricked parses, refresh proceeds
2048 parses parses
  • Recommended final gate before release: a device smoke test (open wallet, sync, send) since the harness exercises the login/fetch/parse path but not sends.

The previous pin (cedb2164, Nov 2025) parses get_address_txs with
wire::max_element_count<config::max_txes_in_rpc> = 2048. Any wallet
whose transaction list exceeds that (candidate-spend entries grow
monotonically with wallet age) fails the parse on every refresh,
resets passed_login, and re-logins every 30s forever: the sync circle
never progresses while the server stays perfectly healthy. Verified
against production and reproduced deterministically at the 2048/2049
boundary with the node addon harness
(~/git/projects/monero-sync-tool/lwsf-2048-repro).

Upstream da8e261 (Dec 2025) replaces the count cap with a
min_element_size byte guard. The five commits absorbed alongside it:
SSL CA support, rpc timeout adjustments, http path prefixing, a
connect-status fix, and a subaddr lookahead update.

Patch changes: re-anchored the invoke_payload replace onto the new
upstream text (prefix parameter + explicit connect); the Nym branch now
runs before the socket connect so Nym wallets never open a direct TCP
connection; the build now fails loudly if the patch anchors stop
matching instead of silently shipping an unpatched client.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant