Skip to content
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

RangeError: Invalid array length when calling broadcastDynamic(Infinity) #2715

Open
dilame opened this issue May 8, 2024 · 1 comment
Open
Labels
bug Something isn't working

Comments

@dilame
Copy link
Contributor

dilame commented May 8, 2024

What version of Effect is running?

3.1.2

What steps can reproduce the bug?

import { Effect, Stream } from 'effect';

const intervalStream = Stream.async(() => {}).pipe(Stream.broadcastDynamic(Infinity));

const test = Effect.gen(function* () {
    yield* intervalStream;
});

Effect.runPromise(Effect.scoped(test));

What is the expected behavior?

I expect either broadcasted stream without backpressure or clear error from Effect.

What do you see instead?

tsx ./src/effect.ts
node:internal/process/promises:289
            triggerUncaughtException(err, true /* fromPromise */);
            ^

RangeError: Invalid array length
    at Function.from (<anonymous>)
    at constructor (/Users/bowzee/WebstormProjects/sandbox/node_modules/effect/src/internal/pubsub.ts:371:24)
    at requestedCapacity (/Users/bowzee/WebstormProjects/sandbox/node_modules/effect/src/internal/pubsub.ts:146:12)
    at /Users/bowzee/WebstormProjects/sandbox/node_modules/effect/src/internal/pubsub.ts:78:21 {
  name: '(FiberFailure) RangeError',
  [Symbol(effect/Runtime/FiberFailure)]: Symbol(effect/Runtime/FiberFailure),
  [Symbol(effect/Runtime/FiberFailure/Cause)]: {
    _tag: 'Die',
    defect: RangeError: Invalid array length
        at Function.from (<anonymous>)
        at constructor (/Users/bowzee/WebstormProjects/sandbox/node_modules/effect/src/internal/pubsub.ts:371:24)
        at requestedCapacity (/Users/bowzee/WebstormProjects/sandbox/node_modules/effect/src/internal/pubsub.ts:146:12)
        at EffectPrimitive.effect_instruction_i0 (/Users/bowzee/WebstormProjects/sandbox/node_modules/effect/src/internal/pubsub.ts:78:21)
        at FiberRuntime.Sync (/Users/bowzee/WebstormProjects/sandbox/node_modules/effect/src/internal/fiberRuntime.ts:1076:22)
        at <anonymous> (/Users/bowzee/WebstormProjects/sandbox/node_modules/effect/src/internal/fiberRuntime.ts:1308:53)
        at f (/Users/bowzee/WebstormProjects/sandbox/node_modules/effect/src/internal/tracer.ts:93:19)
        at runLoop (/Users/bowzee/WebstormProjects/sandbox/node_modules/effect/src/internal/fiberRuntime.ts:1298:28)
        at evaluateEffect (/Users/bowzee/WebstormProjects/sandbox/node_modules/effect/src/internal/fiberRuntime.ts:891:27)
        at start (/Users/bowzee/WebstormProjects/sandbox/node_modules/effect/src/internal/fiberRuntime.ts:945:14)
  }
}

Node.js v21.4.0

Additional information

Just by the way – is there a way to broadcast without maximumLag? I don't need it because i'm building WS client

@dilame dilame added the bug Something isn't working label May 8, 2024
@dilame
Copy link
Contributor Author

dilame commented May 9, 2024

Seems like currently there is no way to broadcast a stream without maximumLag.

I think it makes sense to borrow the experience of RxJS team, which initially have had different operators for different types of broadcasting, and it was hell to understand all of them, but in the end of the day they came to elegant solution:

share({
  connector: () => new ReplaySubject(1),
})

Effect could also have a share operator which would accept the abstract connector of Queue type, and users will have maximum freedom of configuration plus it is easier to understand, because you can see what's going on under the hood

Stream.share({
  connector: () => PubSub.unbounded<number>(),
})

or

Stream.share({
  connector: () => PubSub.dropping<number>(2),
})

or

Stream.share({
  connector: () => Queue.sliding<number>(2),
})

or anything:)

The only thing that embarrassing me is the necessity to manually specify generic of PubSub value.

PS actually this message looks like a separated feature request, maybe it makes sense to create a new issue for it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant