Skip to content

Add an opt-in Effect driver with explicit clock and asynchronous ownership #43

Description

@0thernet

Add an opt-in Effect driver with explicit clock and asynchronous ownership

Direct's existing synchronous session, additive FIFO clock, store generation fences and exact browser evidence remain unchanged. Add an opt-in @hraness/direct/effect export for applications whose asynchronous control layer uses Effect 3.22.1. The integration is development-only and must remain absent from production graphs.

The driver owns a single runtime/service graph, admitted operations and asynchronous shutdown. Existing session.dispose() synchronously fences new work and signals cancellation; an explicit awaited driver close joins owned work and records failures. Operations acquire Direct activity and retain the generation at admission, so late work cannot commit into a reset world. Quiescence accounts for Direct activity and driver-owned operations/finalization. Expected failures, defects, interruption and cleanup failures remain observable rather than becoming successful fallback values.

Two explicit timing contracts will be documented and tested. Existing Direct FIFO logical waits retain their additive semantics (concurrent 10/20 waits end at 30). The new driver may offer a separate deadline-clock mode for Effect-native tests (concurrent 10/20 sleeps finish by 20) only with one authoritative clock, deterministic admission/tie ordering and an independent expected-trace oracle. The integration must never silently reinterpret the old clock or claim to simulate native browser/audio/process scheduling. Live clock operation remains available for browser composition.

The API will expose runtime construction, tracked execution, generation-bound store access, observation, cancellation and awaited shutdown without changing core session/manifest wire formats. A neutral resource/controller example will demonstrate the whole path, including reset and disposal. Exact names and signatures will be included in the PR after the initial API design is reviewed.

Validation includes hand-written expected traces before implementation; positive/negative architecture checks through the actual CLI gate; interruption and late foreign completion; primary plus finalizer failures; reset fencing; construction/disposal races; concurrent deadline sleeps versus existing FIFO behavior; packed-consumer export/import boundaries; and Direct's unchanged aggregate gate including browser and React Native examples. No product-private code or fixtures enter this public repository.

This issue covers an additive integration, not a wholesale core rewrite, general workflow engine, production dependency migration or coding-model benchmark. Changes ship only after required independent review, package checks and normal repository delivery gates.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions