Skip to content

Conversation

@JoseSK999
Copy link
Contributor

@JoseSK999 JoseSK999 commented Jul 9, 2025

What is the purpose of this pull request?

  • Bug fix
  • Documentation update
  • New feature
  • Test
  • Other:

Which crates are being modified?

  • floresta-chain
  • floresta-cli
  • floresta-common
  • floresta-compact-filters
  • floresta-electrum
  • floresta-watch-only
  • floresta-wire
  • floresta
  • florestad
  • Other:

Description

We have been getting the "EOF while parsing a string" error occasionally in our electrum request tests, as explained in #536.

It seems that sometimes we don't read the full response from the TcpStream, likely because we read anything that is already on the stream, even if only a fraction of the message. So I am trying to fix it by reading a full line, until we reach a \n (that is, until we've read the full response).

EDIT: I have indeed found that the message that we read from electrum looks like this:

"[{\"id\":1830541884,\"jsonrpc\":\"2.0\",\"result\":\"00000020d74d37f6759b25522f46a3137323cc10954be994298e51be183c8f289601000025f8179af40c198c197ceaf75521a25dce556ba81dcb2929fa2c645fbe965a78aa864e5fae77031eb2b41500\"},{\"id\":925535606,\"jsonrpc\":\"2.0\",\"result\":{\"count\":261,\"hex\":\"000000206add106bf6fdc2a5bf71ceb1c64fcaec3c79b51d0defbc3b019fbb57a8...

(a lot of headers in hex here)

\",\"max\":2016}},{\"id\":2644504369,\"jsonrpc\":\"2.0\",\"result\":{\"height\":0,\"hex\":\"0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a008f4d5fae77031e8ad22203\"}}]\n"

And that when we fail, the response we've read ends while at the headers hex, (i.e., we haven't finished reading the full response).

Fixes #536

Notes to the reviewers

An easy way to reproduce the error is to use a random, large number of headers to request, such that the electrum server takes a bit of time and our tests only read a partial response:

        let block_headers_req = vec![
            Value::Number(Number::from(rand::random::<u32>() % 2000)),
            Value::Number(Number::from(10)),
            method,
        ];

With such request at line 1200 I get the error on first or second try locally, but with this PR it passes.

@Davidson-Souza Davidson-Souza added bug Something isn't working functional tests CI A change or issue related to CI labels Jul 9, 2025
We have been getting the `"EOF while parsing a string"` error occasionally in our electrum request tests.

It seems that sometimes we don't read the full response from the TcpStream, likely because we read anything that is already on the stream without knowing if all the data is already there. So I am **trying** to fix it by reading a full line, until we reach a `\n`, which is the terminator used by electrum responses.
@JoseSK999 JoseSK999 force-pushed the fix-electrum-tests branch from 139191b to e0d5e51 Compare July 9, 2025 17:34
Copy link
Member

@Davidson-Souza Davidson-Souza left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK e0d5e51

@Davidson-Souza Davidson-Souza merged commit 8762066 into vinteumorg:master Jul 10, 2025
10 checks passed
@JoseSK999 JoseSK999 deleted the fix-electrum-tests branch July 10, 2025 14:43
Davidson-Souza pushed a commit to Davidson-Souza/Floresta that referenced this pull request Jul 12, 2025
We have been getting the `"EOF while parsing a string"` error occasionally in our electrum request tests.

It seems that sometimes we don't read the full response from the TcpStream, likely because we read anything that is already on the stream without knowing if all the data is already there. So I am **trying** to fix it by reading a full line, until we reach a `\n`, which is the terminator used by electrum responses.
@Davidson-Souza Davidson-Souza mentioned this pull request Jul 12, 2025
18 tasks
Davidson-Souza added a commit that referenced this pull request Jul 13, 2025
* wire: don't spam the logs with `PeerNotFound` (#559)

* running_node: call maybe_create_connection

We are using `create_connection` directly, but this function assumes
you've checked whether we are not connected with our `--connec` peer.
If we don't check it, we will see the `PeerAlreadyExists` error over
and over again. `maybe_create_connection` also helps using the
fixed peers and dns seeds if we don't have any available addresses
to work with

Therefore, I'm replacing `create_connection` with `maybe_create_connection`
for `check_connections`.

* addr_man: don't return connected peers

This will cause `node` to keep loggin `PeerAlreadyExists`, since it
won't try to connect with the same peer twice.

* Fix electrum tests: read full responses (#560)

We have been getting the `"EOF while parsing a string"` error occasionally in our electrum request tests.

It seems that sometimes we don't read the full response from the TcpStream, likely because we read anything that is already on the stream without knowing if all the data is already there. So I am **trying** to fix it by reading a full line, until we reach a `\n`, which is the terminator used by electrum responses.

* Enable feature-gate banners in docs (#567)

I have added `#![cfg_attr(docsrs, feature(doc_auto_cfg))]` to each lib.rs to enable such banners in our docs.

To generate them we require the `--cfg docsrs` flag. I have updated our `just` recipe, which now documents all features. This is nice to show the users all options available under each feature.

Because we document all features I had to do an exception for the florestad `kv-chainstore` one to avoid a compiler error.

* fix: re-index didn't apply changes to chainstate (#562)

Before this commit, the re-index code would find the right place
where we would work from, but not apply it to our chain. This could
create spurious errors like #551.

This commit fixes that, and also improves how we handle accumulators
on re-indexes. We now try to find our latest accumulator, move
validation index there, nad mark future blocks as `HeadersOnly` to
not have problems with `BlockDoesntExtendTip`.

* chore: remove the `futures` crate (#564)

When I started this project, we used async-std as async runtime. async-std did lack some features, like oneshot channes and some macros like select!, for that reason, I've used the futures crate to get some of those functionalities. However, since #172, we use tokio as async runtime. And tokio does have those features. So I'm removing futures as dependencies.

tokio also has out-of-the-box support for ctr-c handling, so I'm using it instead of the crate.

I've also made the public methods in florestad async. This simplifies some stuff, and shouldn't be a problem, since these methods should only be called with a running runtime. If you need to use them in a sync environment, use a thin wrapper that owns florestad and the runtime. Then block_on every call.

* remove futures from floresta-electrum

* remove futures and ctrc from florestad and wire

* remove futures from floresta

---------

Co-authored-by: S \times 3 🗿 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working CI A change or issue related to CI functional tests

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug] Test - Intermittent network failure

2 participants