deno: Error: Another accept task is ongoing :: JS Native classes making HTTP dispatcher fail.

Note: This is a really strange bug, so I would like to ask you for patience while reading it.

[Details] First, I would like you to see this video because it will be hard to explain with only words: Click here to see video I have attached this video in .ZIP format at the end of the issue if you do not feel comfortable with google drive

– What you saw in this video is that a class with no imports whatsoever (I say this because at first I thought imports were making the HTTP dispatcher fail) is making the http dispatcher fail. It’s been happening to new classes on my code no matter whether it has imports or no as you saw in the video. I have spent more than a day to find the root of the problem in order to be able to record this video. I can create any class in any folder, and it will make the http dispatcher fail, no matter what the content of the class is. It is also happening to both static and non-static methods, it is also happening to classes without methods. so if I only import the class and as soon as I call it like this MyClass; (so no effect at all on the code), it will make the HTTP dispatcher fail.

Update: It is happening not only with JS classes, but also empty defaults (export default {}) & functions (export function MyFunction() {}), with any class name, with any method name…

[Context] It is impossible for me to provide a small context or reproducible context because I do not even know what the context is. It happens randomly to new classes, one class may cause the HTTP dispatcher fail, but another class may work just fine. When finding the causes and playing around with the code, I moved the class you saw in the video to a folder inside a folder inside a folder, and it worked fine, then I got the class out of the folder, and it started failing again: I say this just to demonstrate how random it is.

[Additional] I have wiped out my DENO_DIR, but it didn’t do anything, the error was still being thrown.

I didn’t want to open this issue until being sure it was a real issue/bug. As per my conversation with @lucacasonato where I share these same details, we agreed on the weirdness of this.

[Stacktrace]

 Error: Another accept task is ongoing
    at unwrapResponse ($deno$/ops/dispatch_json.ts:42:11)
    at Object.sendAsync ($deno$/ops/dispatch_json.ts:93:10)
    at async ListenerImpl.accept ($deno$/net.ts:63:17)
    at async Server.acceptConnAndIterateHttpRequests (server.ts:212:14)
    at async MuxAsyncIterator.callIteratorNext (mux_async_iterator.ts:30:31)

[Code details] This is happening in Mandarine Framework. You can find the failing code in the branch make-everything-a-proxy.

1. Download the mentioned branch (make-everything-a-proxy)
2. Go to the root of it in your computer
3. Run deno run --config tsconfig.json --allow-net --allow-read examples/example-1.ts

OrmCoreDecoratorsProxy which is the class that is making the HTTP dispatcher fail at this time, is being called in /orm-core/core/decorators/entityDecorator.ts Line 16. (Inside decorator method “Table”)

OrmCoreDecoratorsProxy is located in /orm-core/proxys/ormCoreDecorators.ts

I would like to mention that the decorator Table where the problem is happening as described before is not even being called in the file that’s being ran (examples/example-1.ts), so the code is never processing OrmCoreDecoratorsProxy, the very very simple fact of putting it in the code is making the HTTP dispatcher fail somehow.

[OS] MacOS Mojave 10.14.6

[Environment] deno 1.1.2 v8 8.5.216 typescript 3.9.2

Update After testing with many versions of Deno, this started happening in version 1.0.3 as it is not happening in 1.0.2

---

cc @lucacasonato

screen-capture (3).webm.zip