SqlResolver.findById causes All fibers interrupted without errors when batched

[jonathanpowers-storable]

What version of Effect is running?

3.13.2

What steps can reproduce the bug?

I've created a simple reproduction here: https://github.com/jonathanpowers-storable/issue-effect-sql-resolver

When I try to execute a SqlResolver.findById inside of i.e. Effect.all or Effect.forEach and I do so with concurrency and batching enabled, it simply says All fibers interrupted without error and exits the program.

I've tried to walk through it using a step debugger, but I can't find the spot where the interrupt is being triggered. I can see the batched request show up in the devtools, so I assume the problem is happening during the process of matching results to requests.

What is the expected behavior?

Should be able to batch sql requests when using SqlResolver.findById by setting concurrency and batching in a parent loop.
Should return a success with the result or a failure with the relevant error, rather than an interrupt without any additional information.

What do you see instead?

[18:53:04.369] ERROR (#0):
All fibers interrupted without errors.

Additional information

Dependency Versions

{
    "@effect/experimental": "^0.41.2",
    "@effect/opentelemetry": "^0.44.2",
    "@effect/platform": "^0.77.2",
    "@effect/platform-node": "^0.73.2",
    "@effect/sql": "^0.30.2",
    "@effect/sql-sqlite-node": "^0.31.2",
    "effect": "^3.13.2"
}

Devtools

Reproduction
https://github.com/jonathanpowers-storable/issue-effect-sql-resolver

[f15u]

Are you using Request/RequestResolver?

I remember having the same problem and it was inside the RequestResolver implementation not completing the request correctly with Request.completeEffect

[jpowersdev]

Thanks for chiming in! It does seem that SqlResolver uses RequestResolver under the hood. It also seems that this is specific to SqlResolver.findById in scenarios with duplicate identifiers.

I was able to achieve the desired result using SqlResolver.grouped and taking the first element of the resulting array for each element, but that further makes me think this is a bug with the way findById is implemented.

If I get a chance to dig into this more I can add more examples to my reproduction