test: always connect peers more realistically #856
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
EvanHahn
commented
Sep 23, 2024
Comment on lines
-211
to
-251
| /** | ||
| * Create a Mapeo replication stream. This replication connects the Mapeo RPC | ||
| * channel and allows invites. All active projects will sync automatically to | ||
| * this replication stream. Only use for local (trusted) connections, because | ||
| * the RPC channel key is public. To sync a specific project without | ||
| * connecting RPC, use project[kProjectReplication]. | ||
| * | ||
| * @param {boolean} isInitiator | ||
| */ | ||
| [kManagerReplicate](isInitiator) { | ||
| const noiseStream = new NoiseSecretStream(isInitiator, undefined, { | ||
| keyPair: this.#keyManager.getIdentityKeypair(), | ||
| }) | ||
| return this.#replicate(noiseStream) | ||
| } | ||
|
|
EvanHahn
added a commit
that referenced
this pull request
Sep 24, 2024
We have a test helper, `invite`, that invites people to projects. It works like this: 1. Tell the invitee(s) to accept any invite they receive. 2. Send the invite. This is fine for most of our tests, where only one invite will be sent to each manager. But we have [at least one test][0] where multiple invites are sent. That can cause a race condition. Imagine the following scenario where `invite` is called twice: 1. Tell the invitee to accept any invite they receive (listener 1). 2. Tell the invitee to accept any invite they receive (listener 2). 3. Send the first invite. 4. Both listeners fire, sending one valid "accept" response and one that gets dropped. 4. Send the second invite. There are no listeners, and the test hangs. This commit changes `invite`. Now, it works like this: 1. Generate an invite ID. 2. Tell the invitee(s) to accept any invite with that ID. 3. Send the invite. As far as I know, this isn't a problem today. But an [upcoming test change][1] causes this to happen much more reliably, so I think this is worth fixing. (I think it's worth fixing even without that upcoming change. Also, I tested this with those changes and it does, indeed, fix hung tests.) [0]: https://github.com/digidem/comapeo-core/blob/d2e5590aa749b690e5c07c3b64791db5e403ee29/test-e2e/sync.js#L530 [1]: #856
EvanHahn
force-pushed
the
connect-peers-realistically-in-tests
branch
from
053346a
to
0d8554d
Compare
EvanHahn
changed the base branch from
main
to
fix-test-invite-race-conditions
EvanHahn
added a commit
that referenced
this pull request
Sep 26, 2024
We have a test helper, `invite`, that invites people to projects. It works like this: 1. Tell the invitee(s) to accept any invite they receive. 2. Send the invite. This is fine for most of our tests, where only one invite will be sent to each manager. But we have [at least one test][0] where multiple invites are sent. That can cause a race condition. Imagine the following scenario where `invite` is called twice: 1. Tell the invitee to accept any invite they receive (listener 1). 2. Tell the invitee to accept any invite they receive (listener 2). 3. Send the first invite. 4. Both listeners fire, sending one valid "accept" response and one that gets dropped. 4. Send the second invite. There are no listeners, and the test hangs. This commit changes `invite`. Now, it works like this: 1. Generate an invite ID. 2. Tell the invitee(s) to accept any invite with that ID. 3. Send the invite. As far as I know, this isn't a problem today. But an [upcoming test change][1] causes this to happen much more reliably, so I think this is worth fixing. (I think it's worth fixing even without that upcoming change. Also, I tested this with those changes and it does, indeed, fix hung tests.) [0]: https://github.com/digidem/comapeo-core/blob/d2e5590aa749b690e5c07c3b64791db5e403ee29/test-e2e/sync.js#L530 [1]: #856
Our tests currenly connect `MapeoManager`s in two ways: 1. By starting peer discovery servers and connecting. This is similar to what the real app does. 2. By manually creating streams and connecting them in tests. This is less realistic. This commit removes the second way because: - it is less realistic - it lets us remove some test-only code in the `src/` directory - it will make an upcoming change easier I also tried to fix a possible (test-only) race condition, which *could* have been a reason for the less realistic option: 1. Start connecting peers by calling `connectPeers()`. This begins the process of starting peer discovery servers. 2. Disconnect them by calling the callback returned by `connectPeers()`. 3. The peer discovery servers start, and begin connecting. *This is bad* because we already wanted to disconnect!
EvanHahn
force-pushed
the
connect-peers-realistically-in-tests
branch
from
0d8554d
to
2e9e219
Compare
gmaclennan
approved these changes
Oct 29, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I recommend reviewing this with whitespace changes disabled.
Our tests currently connect
MapeoManagers in two ways:This commit removes the second way because:
src/directoryI also tried to fix a possible (test-only) race condition, which could have been a reason for the less realistic option:
connectPeers(). This begins the process of starting peer discovery servers.connectPeers().