Question: Is bidirectional streaming with persistent isolates/workers in scope?

[kartikey321]

Summary

I wanted to ask whether true bidirectional streaming with a persistent isolate is in scope for this package,
or part of any future roadmap.

My concrete use case is a persistent WebSocket-style workflow:

• keep message handling/state syncing/parsing logic inside a long-lived isolate or worker
• let the main isolate send outbound events/control messages to it at any time
• let the isolate/worker continuously emit processed/parsed data back to the main isolate
• avoid tying this communication to a single compute() request/response lifecycle

In other words, I am looking for a persistent channel where both sides can send messages independently.

Why I am asking here

I found packages such as stream_isolate and typed_isolate that cover similar bidirectional isolate
communication on native Dart/Flutter platforms.

The reason I am asking here is that isolate_manager already has a broader cross-platform story around VM
isolates, Web Workers, and WASM. So I wanted to understand whether a stream-first bidirectional API fits this
package’s scope.

Current model

From reading the package, IsolateManager currently seems centered around a task queue model:

final result = await isolate.compute(input);

createCustom supports multiple outputs during a task through controller.sendResult() and callback, which is
useful for progress/result streaming. But the lifecycle still appears tied to an active compute() call and
final callback completion.

For my use case, the desired shape is closer to a persistent channel/actor model:

  final bridge = await IsolateBridge.spawn<Input, Output>(worker);

  bridge.output.listen((event) {
    // processed/parsed data from worker -> main
  });

  bridge.send(input);       // outbound event/control message main -> worker
  bridge.pipe(inputStream); // optional Stream<Input> -> worker

Inside the worker:

  void worker(bridge) {
    final socket = /* persistent websocket or socket-like source */;

    bridge.input.listen((message) {
      // main -> worker control/outbound event
      // update state, send over socket, etc.
    });

    socket.listen((rawMessage) {
      final parsed = parseAndApplyState(rawMessage);
      bridge.send(parsed); // worker -> main processed data
    });
  }

Question

Is this kind of bidirectional streaming / persistent channel API something you would consider in scope for isolate_manager?

If yes, I would be interested in discussing a possible design before attempting an implementation.

If not, that is also totally fine, I can treat it as a separate abstraction built specifically around stream-to-stream isolate communication.

[lamnhan066]

If you see the source code of the IsolateManagerFunction.customFunction, you can see this:

  static Future<void> customFunction<R, P>(
    /// A default parameter that used by the package.
    dynamic params, {
    required IsolateOnEventCallback<R, P> onEvent,
    IsolateOnInitCallback<R, P>? onInit,
    IsolateOnDisposeCallback<R, P>? onDispose,
    bool autoHandleException = true,
    bool autoHandleResult = true,
  }) async {
    // Initialize the controller for the child isolate. This function will be declared
    // with `Map<String, dynamic>` as the return type (.sendResult) and `String` as the parameter type (.sendMessage).
    late IsolateManagerController<R, P> controller;
    StreamSubscription<P>? subscription;

    controller = IsolateManagerController(
      params,
      onDispose:
          onDispose == null
              ? null
              : () async {
                onDispose(controller);
                await subscription?.cancel();
                await controller.close();
              },
    );

    await onInit?.call(controller);

    // Listen to messages received from the main isolate; this code will be called each time
    // you use `compute` or `sendMessage`.
    subscription = controller.onIsolateMessage.listen((message) async {
      // Use try-catch to send the exception to the main app
      try {
        final value = await onEvent(controller, message);
        if (autoHandleResult) {
          controller.sendResult(value);
        }
      } catch (err, stack) {
        // Send the exception to your main app
        if (autoHandleException) {
          controller.sendResultError(IsolateException(err, stack));
        } else {
          rethrow;
        }
      }
    });

    controller.initialized();
  }

You can write yourOwnCustomFunction version to serve your purpose. You just need to ensure that controller.initialized() have to be called to make it works.

If you want to generate a JS Worker, you need to wrap it in a function that takes only a single dynamic params argument, like this:

@isolateManagerCustomWorker
void isolateYourOwnCustomFunction(dynamic params) {
  yourOwnCustomFunction(params, customParams,...);
}

If you still have any questions or considerations, please let me know.

[kartikey321]

Thanks @lamnhan066 , that makes sense, and I agree that at a basic level this can be built by writing a custom wrapper
around customFunction and making sure controller.initialized() is called.

But after actually implementing this, I think the gap is a bit bigger than just “wrap customFunction”.

What I found is that customFunction helps on the worker side, but the overall package still behaves around a
request/response or queue-style model. For the kind of persistent bidirectional channel I need, the harder
parts are things like startup/init handshake, lifecycle ownership, shutdown behavior, error propagation, and
keeping the behavior consistent across VM isolates and web workers.

That is basically why my implementation turned into a separate bridge abstraction instead of only a helper
around customFunction. A wrapper is enough to experiment, but for a stable API I do not think it is enough by
itself.

Because of that, I do not want to force this upstream too early.

My plan for now is to keep maintaining it in my fork https://github.com/kartikey321/isolate_manager.git, make it stable for prod, let the behavior settle a bit, and
only then see whether it makes sense to upstream some or all of it if it fits the direction of the package.

So I am not pushing for a PR right now. I mainly wanted to understand whether this kind of persistent bridge
abstraction is something you would consider in scope for isolate_manager, or whether it is better kept as a
separate layer on top.

[lamnhan066]

I think if it can be built on top of isolate_manager without chaning the behavior, it should be kept as a separate layer to avoid making isolate_manager too complicated to use. Thank you for the idea.

[kartikey321]

Thanks @lamnhan066 — that direction (separate layer, don't change isolate_manager's behavior) is what I am following right now
The whole IsolateBridge / IsolateBridgePool abstraction now lives in a standalone wrapper package (isolate_bridge) that just depends on isolate_manager.

Doing it surfaced only two small things that stop the wrapper from building cleanly on the public API — both behavior-neutral, and one is a plain bug fix worth having regardless:

1. Bug fix — worker isolate leaks after the main side closes. IsolateContactorControllerImpl.close() doesn't close the IsolateChannel sink, so the ReceivePort stays open and the worker never exits.
   → fix: close IsolateChannel sink on dispose so worker isolates can exit kartikey321/isolate_manager#1
2. Export — opt-in isolate_manager_advanced.dart exposing the low-level IsolateContactorController (additive; main surface unchanged).
   → feat: expose low-level IsolateContactorController via opt-in library kartikey321/isolate_manager#2

Both PRs were generated with Claude Code and verified end-to-end.

I did not need any change to the high-level IsolateManagerController.
isolate_manager's own suite stays green (150 VM + 128 web); the wrapper imports only isolate_manager.dart + the new advanced export (zero src/) and passes 31 VM + 39 web.

If you're open to these two, I'll send them as PRs here. The bridge itself stays in its own package, as you suggested.

[kartikey321]

@lamnhan066 I believe we can discuss what to merge what to not.

These prs are the first draft of what we can expose from the package that's why I raised those prs against my fork not the main isolate manager

I argue that the first pr about the bug fixes should be merged

While for the second pr
I had to expose the low level classes for the bridge otherwise I would be fighting the internal queue system of isolate manager.
I was facing another issue in isolatebridge I had to rewire most of the logic as currently it is nested in the isolate manager package and we wouldn't want that many changes in it to make it modular to export different parts of the system

We can discuss about the second pr that we want that sort of changes or not.
If exporting the low level classes is not favourable for the package, I have no issues keeping the isolatebridge as a separate package