TypeError: Cannot use 'in' operator to search for '_op' in undefined

[dilame]

What version of Effect is running?

3.1.2

What steps can reproduce the bug?

import {Effect, TestClock, Console, Schedule} from "effect"

const test = Effect.gen(function* () {
    const sleeps = yield* TestClock.sleeps();
    console.log(sleeps);

}).pipe(Effect.repeat(Schedule.addDelay(Schedule.forever, () => '1 second')))

Effect.runPromise(test)

What is the expected behavior?

No response

What do you see instead?

node:internal/process/promises:289
            triggerUncaughtException(err, true /* fromPromise */);
            ^

TypeError: Cannot use 'in' operator to search for '_op' in undefined
    at runLoop (/Users/bowzee/WebstormProjects/sandbox/node_modules/effect/src/internal/fiberRuntime.ts:1292:20)
    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)
    at <anonymous> (/Users/bowzee/WebstormProjects/sandbox/node_modules/effect/src/internal/runtime.ts:92:18)
    at resolve (/Users/bowzee/WebstormProjects/sandbox/node_modules/effect/src/internal/runtime.ts:283:38)
    at new Promise (<anonymous>)
    at <anonymous> (/Users/bowzee/WebstormProjects/sandbox/node_modules/effect/src/internal/runtime.ts:278:3)
    at Module.<anonymous> (/Users/bowzee/WebstormProjects/sandbox/node_modules/effect/src/internal/runtime.ts:259:32)
    at <anonymous> (/Users/bowzee/WebstormProjects/sandbox/src/effect.ts:24:8)
    at ModuleJob.run (node:internal/modules/esm/module_job:218:25) {
  name: '(FiberFailure) TypeError',
  [Symbol(effect/Runtime/FiberFailure)]: Symbol(effect/Runtime/FiberFailure),
  [Symbol(effect/Runtime/FiberFailure/Cause)]: {
    _tag: 'Die',
    defect: TypeError: Cannot use 'in' operator to search for '_op' in undefined
        at runLoop (/Users/bowzee/WebstormProjects/sandbox/node_modules/effect/src/internal/fiberRuntime.ts:1292:20)
        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)
        at <anonymous> (/Users/bowzee/WebstormProjects/sandbox/node_modules/effect/src/internal/runtime.ts:92:18)
        at resolve (/Users/bowzee/WebstormProjects/sandbox/node_modules/effect/src/internal/runtime.ts:283:38)
        at new Promise (<anonymous>)
        at <anonymous> (/Users/bowzee/WebstormProjects/sandbox/node_modules/effect/src/internal/runtime.ts:278:3)
        at Module.<anonymous> (/Users/bowzee/WebstormProjects/sandbox/node_modules/effect/src/internal/runtime.ts:259:32)
        at <anonymous> (/Users/bowzee/WebstormProjects/sandbox/src/effect.ts:24:8)
        at ModuleJob.run (node:internal/modules/esm/module_job:218:25)
  }
}

Node.js v21.4.0

Additional information

I understand, that my code makes not too much sense, but i guess it should not lead to TypeError

[mikearnaldi]

To use TestClock you need to provide a TestContext like:

import {Effect, TestClock, TestContext, Schedule} from "effect"

const test = Effect.gen(function* () {
    const sleeps = yield* TestClock.sleeps();
    console.log(sleeps);

}).pipe(Effect.repeat(Schedule.addDelay(Schedule.forever, () => '1 second')))

Effect.runPromise(test.pipe(Effect.provide(TestContext.TestContext)))

The reason this is not tracked at the type level is because otherwise test implementations wouldn't be composable with app code so we opted for a fiber ref

[dilame]

Yes, i understand that i need to provide TestContext in order to use TestClock, i also understand that it is not tracked at type level, but the error in runtime doesn't provide a clear understanding of whats going wrong, is it intended?

[mikearnaldi]

We can try to improve the error message but not sure we have enough info at runtime to make it nice

[DScheglov]

We can try to improve the error message but not sure we have enough info at runtime to make it nice

Is there any way to make this code fail at compile time?
Without it, dependency injection works as a dynamic service locator and will cause heavy debugging.

[mikearnaldi]

We can try to improve the error message but not sure we have enough info at runtime to make it nice

Is there any way to make this code fail at compile time? Without it, dependency injection works as a dynamic service locator and will cause heavy debugging.

As explained it is like this intentionally. For typed dependencies you have Context, in this case we use a FiberRef to not have explicit types. If using the TestClock added a dependency to the type you would not be able to use it in place of production code.

[dilame]

not sure we have enough info at runtime to make it nice

Something like "Some of the required dependencies not found" message would be better that TypeError at runtime anyway IMHO:)

And, BTW, maybe we could depend on Clock on type-level, and substitute it with TestClock when needed?

[mikearnaldi]

TestClock has more functions than Clock so depending on Clock wouldn't make a difference

…

On Mon, 20 May 2024, 22:42 Dmitry, ***@***.***> wrote: not sure we have enough info at runtime to make it nice Something like "*Some of the required dependencies not found*" message would be better that TypeError at runtime anyway IMHO:) And, BTW, maybe we could depend on Clock on type-level, and substitute it with TestClock when needed? — Reply to this email directly, view it on GitHub <#2708 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFZAKCQYX2JP6G3UC646PI3ZDJN3JAVCNFSM6AAAAABHLUG6MGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRRGE3TIMBYGQ> . You are receiving this because you commented.Message ID: ***@***.***>