-
Notifications
You must be signed in to change notification settings - Fork 1
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
test: always connect peers more realistically #856
base: main
Are you sure you want to change the base?
Conversation
@@ -27,50 +27,28 @@ const clientMigrationsFolder = new URL('../drizzle/client', import.meta.url) | |||
|
|||
/** | |||
* @param {readonly MapeoManager[]} managers | |||
* @returns {() => void} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This return type was was just incorrect before, I believe.
|
||
for (const manager of managers) { | ||
manager.startLocalPeerDiscoveryServer().then(({ name, port }) => { | ||
if (requestedDisconnect) return |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This check (hopefully) fixes a small possible race condition.
/** | ||
* Replicate a project to a @hyperswarm/secret-stream. Invites will not | ||
* function because the RPC channel is not connected for project replication, | ||
* and only this project will replicate (to replicate multiple projects you | ||
* need to replicate the manager instance via manager[kManagerReplicate]) | ||
* | ||
* @param {Parameters<import('hypercore')['replicate']>[0]} stream A duplex stream, a @hyperswarm/secret-stream, or a Protomux instance | ||
*/ | ||
[kProjectReplicate](stream) { | ||
// @ts-expect-error - hypercore types need updating | ||
const replicationStream = this.#coreManager.creatorCore.replicate(stream, { | ||
// @ts-ignore - hypercore types do not currently include this option | ||
ondiscoverykey: async (discoveryKey) => { | ||
const protomux = | ||
/** @type {import('protomux')<import('@hyperswarm/secret-stream')>} */ ( | ||
replicationStream.noiseStream.userData | ||
) | ||
this.#syncApi[kHandleDiscoveryKey](discoveryKey, protomux) | ||
}, | ||
}) | ||
return replicationStream | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No longer needed either.
/** | ||
* 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) | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No longer needed.
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 do not know what benefit it offers 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!
053346a
to
0d8554d
Compare
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
Depends on #863.
I recommend reviewing this with whitespace changes disabled.
Our tests currenly connect
MapeoManager
s 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()
.