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

chore: add Node 20 to CI #652

Merged
merged 3 commits into from
May 20, 2024
Merged

chore: add Node 20 to CI #652

merged 3 commits into from
May 20, 2024

Conversation

achou11
Copy link
Member

@achou11 achou11 commented May 15, 2024

Adds Node 20 to the matrix for CI, as that's the current LTS and it would seem advisable to be testing on that version in addition to 18 (which is still needed because of our usage of NodeJS Mobile)

@achou11
Copy link
Member Author

achou11 commented May 15, 2024

ooo interesting - test failure on 20: https://github.com/digidem/mapeo-core-next/actions/runs/9099775156/job/25013115175?pr=652#step:6:3694

 # ok 2 - device info written to projects \# time = 359.825798ms
# \# device info sent to peers
#     ok 1 - should be equal
#     ok 2 - should be equal
#     not ok 3 - should be equal
#       ---
#       actual: device0
#       expected: new name
#       operator: is
#       source: |
#               const [peersFromEvent] = await once(manager, 'local-peers')
#               t.is(peersFromEvent.find(isChangedPeer)?.name, 'new name')
#         --------^
#         
#               const updatedLocalPeers = await manager.listLocalPeers()
#       stack: |
#         ./test-e2e/device-info.js:167:9
#         process.processTicksAndRejections (node:internal/process/task_queues:95:5)
#         async ./test-e2e/device-info.js:176:3
#         async Test._run (./node_modules/brittle/index.js:576:7)
#       ...
#     ok 4 - should be equal

@achou11 achou11 requested a review from EvanHahn May 15, 2024 17:12
Copy link
Contributor

@EvanHahn EvanHahn left a comment

Choose a reason for hiding this comment

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

I support this but can we fix the test failure? Happy to help investigate later.

@achou11
Copy link
Member Author

achou11 commented May 15, 2024

haven't been able to reproduce the test failure locally yet 🙃

@EvanHahn
Copy link
Contributor

EvanHahn commented May 15, 2024 via email

@achou11
Copy link
Member Author

achou11 commented May 15, 2024

I don't have a solution but I reproduced it on my machine with no issue. I wonder if it's a Linux thing?

Failure seems to occur on all machines in CI though?

@EvanHahn
Copy link
Contributor

Ah true. Uh...did you run npm rebuild? I don't expect that to be the issue.

@achou11
Copy link
Member Author

achou11 commented May 15, 2024

Ah true. Uh...did you run npm rebuild? I don't expect that to be the issue.

yep, no luck though 🤔

@EvanHahn
Copy link
Contributor

EvanHahn commented May 16, 2024 via email

@achou11
Copy link
Member Author

achou11 commented May 16, 2024

Strange...let me know if I can help at all.

if you can just...fix everything, that would be a great help 👍

@EvanHahn
Copy link
Contributor

EvanHahn commented May 16, 2024 via email

[When peers connect, they exchange device info.][0] If peers make
redundant connections[^1], they can send redundant device info messages.

[In tests, we connect all managers to each other, which includes
redundant connections.][2] As you might expect, this might exchange
redundant device info messages.

This test was failing because of the following sequence of events:

1. Manager A starts connecting to Manager B.
2. Manager B starts connecting to Manager A.
3. The first connection (from event 1) is established and Manager A
   sends its device info.
4. Manager B receives the device info.
5. In the test, `waitForPeers(managers, { waitForDeviceInfo: true })`
   resolves because Manager B has received device info.
6. The second connection (from event 2) is established and Manager A
   resends its device info.
7. In the test, Manager A changes its name and sends its device info
   again.
8. Manager B receives the second device info.
9. Manager B receives the final device info.

The penultimate step was the problem. Once `waitForPeers()` resolved,
our test expected that no more device info messages were in flight, but
that wasn't true.

The failure was intermittent but its failure became more likely when
testing on Node 20.[^2]

[^1]: This can happen if two peers discover each other at the same time
and both connect to each other. This is swiftly resolved, but not before
the redundant device info messages are sent.
[^2]: I don't know why.

[0]: https://github.com/digidem/mapeo-core-next/blob/2eda1269ee8287199c9d9d1ec0ad30a98fad100c/src/mapeo-manager.js#L269
[2]: https://github.com/digidem/mapeo-core-next/blob/2eda1269ee8287199c9d9d1ec0ad30a98fad100c/test-e2e/utils.js#L46-L53
@EvanHahn
Copy link
Contributor

Pushed eb23f66 to fix the problem. It has a wordy explanation about the race condition that happened here.

@achou11 achou11 requested a review from EvanHahn May 20, 2024 07:11
@achou11 achou11 merged commit 0afd07f into main May 20, 2024
7 checks passed
@achou11 achou11 deleted the ac/node-20-ci branch May 20, 2024 15:30
EvanHahn added a commit that referenced this pull request May 20, 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