Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: add js tests to this repo #365

Merged
merged 7 commits into from
Jun 6, 2024
Merged

Conversation

achingbrain
Copy link
Member

Trying to debug these tests in CI is incredibly difficult and since they depend on older versions of previously published modules, if something breaks due to a bug in released code it's very hard to fix it.

Instead follow the pattern in the perf tests and include the full test implementations here.

The changes here seem to make the js-libp2p transport interop CI job much happier!

Trying to debug these tests in CI is incredibly difficult and since
they depend on older versions of previously published modules, if
something breaks it's very hard to fix it.

Instead follow the pattern in the perf tests and include the full
test implementations here.
@MarcoPolo
Copy link
Contributor

MarcoPolo commented May 22, 2024

Instead follow the pattern in the perf tests and include the full test implementations here.

👍. This is what I originally did here. The other impls like Go still have the the interop code in the main repo, and then copy it to their impl repo when make is run. This lets the test live with the repo while still giving you the ability to debug the tests manually.

Related: #364

What did you change to fix it? My hunch is that some timing is off between when the local redis proxy starts and when the test code makes a request for it. This line makes me think that:
Error: connect ECONNREFUSED 127.0.0.1:39771 (note the port 39771, that's not redis, it's likely the local proxy we use to communicate with redis).

}

const proxyServer = http.createServer(requestListener)
proxyServer.listen(0)
Copy link
Contributor

Choose a reason for hiding this comment

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

This is what fixed it. Previously this was:

  await new Promise(resolve => { proxyServer.listen(0, 'localhost', () => { resolve() }) })

The reason this broke it is kind of funny. For whatever reason this now listens on only the IPv6 loopback address ::1, but when we do the fetch:

 fetch(`http://localhost:...

it resolves to the ipv4 loopback address at 127.0.0.1.


Apparently in this environment just doing .listen(0) listens on both ::1 and 127.0.0.1 (unless IPv6 is disabled and you only listen on 127.0.0.1).

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, it's generally better to listen without specifying a host, then it'll bind to all available addresses/interfaces, then the host can resolve "localhost" to whatever it wants and we can have a quiet life 😄

@MarcoPolo
Copy link
Contributor

Can we either:

  1. Merge chore: add [email protected] to transport-interop #359 and then update v1.6 to include an in-repo test (or do the thing where we copy the test from the main repo like Rust and Go do)
  2. Update this PR to include the in-repo test for the last two versions of js-libp2p.

I'd lean for option 1 since #359 should be good to go now after I fixed it with an ugly hack.

@achingbrain
Copy link
Member Author

achingbrain commented May 26, 2024

My preference would still be to use released artefacts to run these tests, if nothing else because installing all the dev tools and building things takes time which will only get worse the more releases there are, but it seems that the runtime environment will change over time (ex, these tests used to pass, now they don't because of the IP4/IP6 thing identified above) so this is probably the pragmatic thing to do.


I see #359 got merged, I didn't realise we were going to add every minor release too - TBH I'm not sure of the utility of testing 1.3, 1.4, 1.5 etc because of how js-libp2p is released:

The transport and identify/ping protocol modules do all the heavy lifting here so are the ones that would be likely to introduce bugs that break things but js-libp2p does not always have a corresponding release for each version of these because the monorepo publish step only releases modules that have changed in order to minimise dependency churn for users.

That is to say, we could be on [email protected] until the end of the year but there could be many @libp2p/tcp releases in the interim, which would not be reflected here.

Instead we could just have the latest js-libp2p major tested here (e.g. whatever the latest released 1.x.x version of libp2p and all @libp2p/* modules is). The js-libp2p repo tests against that in CI, then we can use dependabot to update the lockfile here after each monorepo publish. That should act like a kind of ratchet in that if the current monorepo CI is compatible with the latest released version, and if it's running the same test, then it should be compatible with previous versions too.

For total certainty we'd need have to have versions here for every monorepo publish but that would lead to many jobs here and ever increasing build times.

1.x should be good enough, what do you think?

achingbrain added a commit to libp2p/js-libp2p that referenced this pull request May 28, 2024
achingbrain added a commit to libp2p/js-libp2p that referenced this pull request May 28, 2024
@MarcoPolo
Copy link
Contributor

My preference would still be to use released artefacts to run these tests, if nothing else because installing all the dev tools and building things takes time which will only get worse the more releases there are, but it seems that the runtime environment will change over time (ex, these tests used to pass, now they don't because of the IP4/IP6 thing identified above) so this is probably the pragmatic thing to do.

I'll defer to your opinion on how to do the js-libp2p implementation here. I'll just mention that the time for installing/building is probably a non-issue since we cache the builds anyways. Go and Rust (and others) only build the test once. I would suggest considering following how Go/Rust implement the test in the main repo and copy it during a build. That gives you the benefit of having the test defined alongside the implementation and being able to debug things like this, or, the more likely failure, an incompatibility.

I see #359 got merged, I didn't realise we were going to add every minor release too - TBH I'm not sure of the utility of testing 1.3, 1.4, 1.5 etc because of how js-libp2p is released:

It's only testing 1.5 and 1.6 (the last two versions). The other versions are vestiges that I haven't remove yet.

...
Instead we could just have the latest js-libp2p major tested here (e.g. whatever the latest released 1.x.x version of libp2p and all @libp2p/* modules is). The js-libp2p repo tests against that in CI, then we can use dependabot to update the lockfile here after each monorepo publish. That should act like a kind of ratchet in that if the current monorepo CI is compatible with the latest released version, and if it's running the same test, then it should be compatible with previous versions too.

1.x should be good enough, what do you think?

That sounds fine by me. As long as a given commit is reproducible I'm happy.

@achingbrain
Copy link
Member Author

I would suggest considering following how Go/Rust implement the test in the main repo and copy it during a build. That gives you the benefit of having the test defined alongside the implementation and being able to debug things like this, or, the more likely failure, an incompatibility.

The test in js-libp2p main should be compatible with the currently released major (v1 at the time of writing), so on the face of it, it makes sense to copy over during the build. But if we release v2, it may become incompatible with v1, so we should copy the v1 test from the latest v1.x.x tag and not main, which means we can't change it in response to external breakage (like the localhost docker thing here) and we're back to the current problem.

We can always revisit this later if the situation changes.

@achingbrain achingbrain merged commit fb99e69 into master Jun 6, 2024
3 checks passed
@achingbrain achingbrain deleted the fix/wait-for-healthy-redis branch June 6, 2024 09:53
achingbrain added a commit to libp2p/js-libp2p that referenced this pull request Jun 6, 2024
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.

2 participants