Issue with `Clock.currentTimeNanos` in Cloudflare Workers with `nodejs_compat` flag affecting `@e...
Is anyone using cloudflare workers with effect? I stumbled upon an issue where
I'd very much appreciate if someone could confirm this problem. I created a simple example here https://github.com/bastiankistner/effect-clock-test . It's just a wrangler init starter where you need to run
1.
2.
for 1. it should state something like
and for 2. it should be much lower like
I would assume I can provide an alternative implementation of the Clock service, similar to the default logger? I'll see if that could solve my little problem. But it'd be also great if someone could confirm that this indeed might be an issue. Thanks a lot!
Clock.currentTimeNanos seems to behave differently depending on the compatibility_flags being used. This results in @effect/opentelemetry not properly assigning startTime for traces. Without the flag nodejs_compat, Clock.currentTimeNanos returns the correct value. But when using nodejs_compat, currentTimeNanos seems to start at epoch time (0 seconds). I found an issue in the opentelemetry repo that might be related to it: https://github.com/open-telemetry/opentelemetry-js/issues/5500 I'd very much appreciate if someone could confirm this problem. I created a simple example here https://github.com/bastiankistner/effect-clock-test . It's just a wrangler init starter where you need to run
pnpm install and then1.
pnpm run dev and goto http://localhost:8787/ then check stdout in your terminal2.
pnpm run dev-compat and goto http://localhost:8787/ then check stdout in your terminalfor 1. it should state something like
Clock.currentTimeNanos: 1745444706401999872 and for 2. it should be much lower like
Clock.currentTimeNanos: 624000000I would assume I can provide an alternative implementation of the Clock service, similar to the default logger? I'll see if that could solve my little problem. But it'd be also great if someone could confirm that this indeed might be an issue. Thanks a lot!
