denodrivers / denodrivers/mongo
Client closing leads to BadResource / Interrupted
- Dominant language
- TypeScript
- Stars
- 511
- Forks
- 89
- PR merge metrics
- No merged PRs in 30d
Description
Client closing sometimes leads to the following errors:
1) BadResource
```
error: (in promise) BadResource: Bad resource ID
nwritten += await w.write(arr.subarray(nwritten));
^
at async write (deno:ext/net/01_net.js:33:12)
at async writeAll (https://deno.land/std@0.149.0/streams/conversion.ts:422:17)
at async WireProtocol.send (https://deno.land/x/mongo@v0.31.0/src/protocol/protocol.ts:101:7)
This error was not caught from a test and caused the test runner to fail on the referenced module.
It most likely originated from a dangling promise, event/timeout handler or top-level code.
```
2) Interrupted
```
error: (in promise) Interrupted: operation canceled
rr = await this.#rd.read(this.#buf);
^
at async read (deno:ext/net/01_net.js:28:19)
at async BufReader.read (https://deno.land/std@0.149.0/io/buffer.ts:383:12)
at async BufReader.readFull (https://deno.land/std@0.149.0/io/buffer.ts:415:20)
at async WireProtocol.receive (https://deno.land/x/mongo@v0.31.0/src/protocol/protocol.ts:110:28)
This error was not caught from a test and caused the test runner to fail on the referenced module.
It most likely originated from a dangling promise, event/timeout handler or top-level code.
```
They are, most likely, caused by the fact that [send](https://github.com/denodrivers/mongo/blob/d45dd12f114c14b1e30bc743310374ce50aa678a/src/protocol/protocol.ts#L83) and [receive](https://github.com/denodrivers/mongo/blob/d45dd12f114c14b1e30bc743310374ce50aa678a/src/protocol/protocol.ts#L106) functions never catch anything and their calls ([1](https://github.com/denodrivers/mongo/blob/d45dd12f114c14b1e30bc743310374ce50aa678a/src/protocol/protocol.ts#L63), [2](https://github.com/denodrivers/mongo/blob/d45dd12f114c14b1e30bc743310374ce50aa678a/src/protocol/protocol.ts#L67)) don't use `catch` too.
I'm not quite familiar with this repo, but it looks like one could just catch these errors, which would, however, lead to the scenario when [command queue](https://github.com/denodrivers/mongo/blob/d45dd12f114c14b1e30bc743310374ce50aa678a/src/protocol/protocol.ts#L32) is broken in case of real connection problem. That being said, it looks like this issue is somewhat related to [automatic reconnect feature proposal](https://github.com/denodrivers/mongo/issues/278) – one should distinct errors occurred during `mongoClient.close()` calls (and catch them) and other errors (and try to reconnect, probably).
For anyone who want to make own tests less flaky on client close, I can suggest this workaround (one should use this before `mongoClient.close()`):
```typescript
addEventListener("unhandledrejection", (e) => {
if (
["BadResource", "Interrupted"].includes(e.reason.name) &&
e.reason.stack.includes("deno.land/x/mongo")
) {
e.preventDefault();
}
});
```
If anyone has better workaround, please write it in this thread.
Contributor guide
No contributing guide indexed for this repository
Research direction
Read src/protocol/protocol.ts, especially send, receive, their callers, and the command queue. Reproduce a client close and inspect how BadResource and Interrupted rejections propagate; compare close-time errors with genuine connection failures. Done means client shutdown no longer produces unhandled rejections while real connection failures still follow the intended queue or reconnect behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- deno, mongodb, typescript
- Domain
- backend-api-design, databases
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100