Effect 4.0 Cluster 持久化工作流DurableClock 唤醒时间戳毫秒级归一化修复解析【免费下载链接】effectBuild production-ready applications in TypeScript项目地址: https://gitcode.com/GitHub_Trending/ef/effect导读本文围绕 effect 仓库中fix-durable-clock-fractional-wakeup这一 changeset 补丁深入剖析集群持久化工作流Cluster Durable Workflow中DurableClock唤醒时间的处理机制。你将了解为什么唤醒时间戳必须归一化为整毫秒、Math.ceil在其中的关键作用、分数毫秒在消息存储与分片路由链路中的潜在风险以及仓库源码与测试用例如何印证这一修复。修复背景一条 changeset 补丁说了什么在 effect 仓库的 .changeset/pre/fix-durable-clock-fractional-wakeup.md 中记录了这样一条针对effect包的补丁--- effect: patch --- Normalize cluster durable clock wake-up timestamps to whole milliseconds.翻译过来即将集群持久化时钟cluster durable clock的唤醒时间戳归一化为整毫秒。这是一条典型的patch级别修复——它不改变任何公开 API 的形状也不引入新特性而是修正了底层持久化时钟唤醒链路中一个潜在的精度隐患。需要强调的是这条 changeset 位于.changeset/pre/目录属于发布前预检pre-release阶段的变更记录。要真正理解这条修复的意义必须回到源码中看清DurableClock的完整数据流。DurableClock持久化工作流中的闹钟模块定位与数据模型DurableClock定义在 packages/effect/src/unstable/workflow/DurableClock.ts位于effect/unstable/workflow模块下入口见 packages/effect/src/unstable/workflow/index.ts从 4.0.0 版本开始提供属于实验性unstableAPI。它解决的问题很直观在可持久化、可重放replay的工作流执行中普通的Effect.sleep会随进程重启而丢失因此需要一个可以被持久化调度、跨进程恢复的定时器。源码头部注释对此有清晰说明Durable timers for workflow sleeps.makecreates aDurableClockwith a name, duration, and deferred wake-up signal.其核心数据结构是一个接口export interface DurableClock { readonly [TypeId]: typeof TypeId readonly name: string readonly duration: Duration.Duration readonly deferred: DurableDeferred.DurableDeferredtypeof Schema.Void }name时钟的名字用于在持久化存储中唯一标识duration休眠时长Duration.Durationdeferred一个关联的DurableDeferred当唤醒时刻到来时被完成从而唤醒正在等待的工作流执行。构造器make的实现见 DurableClock.ts会基于名字创建一个持久化 deferred名字形如DurableClock/${options.name}export const make (options: { readonly name: string readonly duration: Duration.Input }): DurableClock ({ [TypeId]: TypeId, name: options.name, duration: Duration.fromInputUnsafe(options.duration), deferred: DurableDeferred.make(DurableClock/${options.name}) })sleep 的两条路径内存短眠 vs 持久化长眠DurableClock.sleep见 DurableClock.ts是工作流代码中实际调用的入口它的行为遵循一个**内存阈值in-memory threshold**策略export const sleep: ( options: { readonly name: string readonly duration: Duration.Input /** * If the duration is less than or equal to this threshold, the clock will * be executed in memory. * * default 60 seconds */ readonly inMemoryThreshold?: Duration.Input | undefined } ) Effect.Effectvoid, never, WorkflowEngine | WorkflowInstance ...流程分三段零时长短路若duration为零直接返回不做任何调度内存路径若duration inMemoryThreshold默认 60 秒defaultInMemoryThreshold Duration.seconds(60)则通过一个名为DurableClock/${options.name}的 in-memory activity 执行普通Effect.sleep(duration)——此时不需要持久化任何状态持久化路径否则从WorkflowEngine与WorkflowInstance服务中取到当前执行上下文调用engine.scheduleClock(instance.workflow, { executionId, clock })将唤醒计划提交给引擎然后yield* DurableDeferred.await(clock.deferred)等待持久化唤醒信号。需要补充的一点是仓库中另一条 changeset durable-clock-zero-threshold.md 修复了显式传入0/0n作为inMemoryThreshold时被误判为未传参而回退到默认 60 秒的问题。这两条 changeset 都作用于同一模块前者保证0阈值语义正确强制走持久化路径后者则保证持久化路径上的时间戳是干净的整毫秒属于同一子系统内的配套修复。引擎侧的 scheduleClock 契约WorkflowEngine服务在 packages/effect/src/unstable/workflow/WorkflowEngine.ts 中声明了scheduleClock契约/** * Schedule a wake up for a DurableClock */ readonly scheduleClock: ( workflow: Workflow.Any, options: { readonly executionId: string readonly clock: DurableClock } ) Effect.Effectvoid它有两种实现内存引擎layerMemory见 WorkflowEngine.ts直接用Effect.delay(options.clock.duration)配合FiberMap.run实现而集群引擎cluster则把唤醒计划编码为一条持久化消息这正是本次修复的焦点。集群引擎唤醒计划如何变成持久化消息ClockPayload 与 ClockRpc在 packages/effect/src/unstable/cluster/ClusterWorkflowEngine.ts 中持久化时钟被建模为一个独立的集群实体class ClockPayload extends Schema.ClassClockPayload(Workflow/DurableClock/Run)({ name: Schema.String, workflowName: Schema.String, wakeUp: Schema.DateTimeUtcFromMillis }) { [PrimaryKey.symbol]() { return this.name } [DeliverAt.symbol]() { return this.wakeUp } } const ClockRpc Rpc.make(run, { payload: ClockPayload }) .annotate(ClusterSchema.Persisted, true) .annotate(ClusterSchema.Uninterruptible, true) const ClockEntity Entity.make(Workflow/-/DurableClock, [ ClockRpc ])三个字段的语义name时钟名称即DurableClock的name同时作为持久化主键workflowName所属工作流的名称用于唤醒时回填wakeUp绝对唤醒时刻其 Schema 为Schema.DateTimeUtcFromMillis——注意这里是从毫秒解析 UTC 时间即该字段在持久化层的原生粒度就是毫秒实现了DeliverAt协议见 packages/effect/src/unstable/cluster/DeliverAt.ts即这条消息应该被延迟投递到wakeUp时刻。scheduleClock 实现分数毫秒从何而来集群引擎的scheduleClock见 ClusterWorkflowEngine.ts实现如下scheduleClock(workflow, options) { return DateTime.now.pipe( Effect.flatMap((now) sendDiscard({ rpc: ClockRpc, address: entityAddressFor({ workflow, entityType: ClockEntity.type, executionId: options.executionId }), payload: { name: options.clock.name, workflowName: workflow._tag, wakeUp: DateTime.mapEpochMillis( DateTime.addDuration(now, options.clock.duration), Math.ceil ) } }) ), Effect.orDie ) }这里的核心逻辑是wakeUp DateTime.mapEpochMillis( DateTime.addDuration(now, options.clock.duration), Math.ceil )取当前时刻now加上时钟时长得到目标时刻DateTime.addDuration(now, options.clock.duration)用DateTime.mapEpochMillis见 packages/effect/src/DateTime.ts 及其内部实现 packages/effect/src/internal/dateTime.ts对该时刻的epoch 毫秒数应用Math.ceil——即向上取整到下一个整数毫秒。mapEpochMillis的内部实现dateTime.ts本质上是取出toEpochMillis(self)应用映射函数f再按原时区重建 DateTimeexport const mapEpochMillis dual(2, (self, f) { const millis f(toEpochMillis(self)) return self._tag Utc ? makeUtc(millis) : makeZonedProto(millis, self.zone) })那么分数毫秒fractional milliseconds从何而来Duration.Input允许传入10000.5这类带小数的毫秒值测试中就有这样的用例见下文而DateTime内部基于Date/ epoch millis 表示DateTime.addDuration的结果可能携带亚毫秒精度。由于ClockPayload.wakeUp的持久化 Schema 是Schema.DateTimeUtcFromMillis毫秒粒度DeliverAt.toMillis见 DeliverAt.ts取出的是epochMilliseconds分数毫秒若原样进入该字段就会在 Schema 编码 / 解码或存储时被截断truncate或舍入round从而与调用方预期的唤醒时刻产生偏差。Math.ceil的语义是宁可晚唤醒不可早唤醒——提前唤醒对于依赖已等待足够时长语义的定时器而言是更危险的错误。向上取整保证了存储值与语义一致唤醒只可能发生在计划时刻之后绝不会在此之前触发。唤醒消息的完整生命周期从投递到恢复理解了归一化修复之后再沿着数据流看一遍持久化唤醒消息如何最终唤醒工作流能够更清楚地体会这条补丁的价值。延迟投递协议ClockPayload通过DeliverAt协议携带自己的投递时间。消息存储层在扫描待处理消息时会过滤尚未到期的请求见 packages/effect/src/unstable/cluster/MessageStorage.tsif (entry?.deliverAt entry.deliverAt now) { continue // 尚未到投递时刻跳过 }内存驱动的saveEnvelope会把DeliverAt.toMillis(message.envelope.payload)的结果存入条目MessageStorage.tsSQL 驱动的实现则将其作为独立的deliverAt列持久化SqlMessageStorage.ts。这一列/字段的粒度就是毫秒整数因此若wakeUp携带亚毫秒部分无论哪条存储路径都必须做出取舍——这正是归一化必须发生在源头scheduleClock的原因。唤醒实体的处理逻辑持久化时钟实体ClockEntity的处理器ClusterWorkflowEngine.ts在消息到达后执行return { run(request) { const deferred DurableClock.make({ name: request.payload.name, duration: Duration.zero }).deferred return ensureSuccess(engine.deferredDone(deferred, { workflowName: request.payload.workflowName, executionId, deferredName: deferred.name, exit: Exit.void })) } }它用消息中携带的name重建同名 deferred并以Exit.void完成它——这正是工作流中DurableDeferred.await(clock.deferred)等待的信号。engine.deferredDone随后会把完成结果持久化并恢复resume挂起的工作流执行使其从上次休眠处继续运行完整逻辑见 WorkflowEngine.ts。整个链路可概括为DurableClock.sleep(duration) └─ engine.scheduleClock() [当前时刻 durationMath.ceil 归一整毫秒] └─ ClockRpc 消息写入 MessageStoragedeliverAt wakeUp 毫秒 └─ 存储层按 deliverAt 延迟投递 └─ ClockEntity 处理器完成持久化 deferred └─ 工作流执行恢复sleep 返回测试印证整毫秒断言与分数毫秒用例仓库测试给出了这条修复的直接证据。在 packages/effect/test/cluster/ClusterWorkflowEngine.test.ts 中有一个名为routes fractional millisecond durable clock wakeups to the workflow shard group的用例专门针对分数毫秒唤醒时间it.effect(routes fractional millisecond durable clock wakeups to the workflow shard group, () Effect.gen(function*() { const driver yield* MessageStorage.MemoryDriver const sharding yield* Sharding.Sharding const scheduled yield* ShardedClockScheduled const startedAt yield* DateTime.now const fiber yield* ShardedClockWorkflow.execute({ id: sharded-clock }) .pipe(Effect.forkChild({ startImmediately: true })) yield* scheduled.await const envelope driver.journal.find((envelope) envelope._tag Request envelope.address.entityType Workflow/-/DurableClock ) assert(envelope) assert.strictEqual(envelope.address.shardId.group, workflow) const deliverAt driver.requests.get(envelope.requestId)?.deliverAt assert.isNumber(deliverAt) assert.strictEqual(deliverAt, DateTime.toEpochMillis(startedAt) 10001) yield* TestClock.adjust(10001) ... }))该用例对应的被测工作流ClusterWorkflowEngine.test.ts故意使用了分数毫秒时长const clock DurableClock.make({ name: ShardedClock, duration: 10000.5 // 10 秒 0.5 毫秒 }) yield* engine.scheduleClock(instance.workflow, { executionId: instance.executionId, clock })注意这里的断言assert.strictEqual(deliverAt, DateTime.toEpochMillis(startedAt) 10001)startedAt整数毫秒加上10000.5本应产生小数但断言期望的是10001——即Math.ceil向上取整后的结果。这个用例同时验证了两件事归一化生效deliverAt是整毫秒且等于起始时刻 时长向上取整分片路由正确消息被路由到shardId.group workflow的 shard group该工作流通过ClusterSchema.ShardGroup注解指定见 ClusterWorkflowEngine.test.ts。此外同文件中的零阈值用例ClusterWorkflowEngine.test.ts通过注入makeWorkflowEngineUnsafe假引擎验证了显式0/0n阈值时DurableClock.sleep只调用scheduleClock与deferredResult而不经过内存 activity——印证了前面提到的配套补丁。修复价值与边界说明为什么必须向上取整而不是截断或四舍五入对定时唤醒语义而言早唤醒比晚唤醒更危险若截断Math.floor/ 隐式toMillis截断工作流可能在目标时刻之前被唤醒破坏至少休眠 N 时长的语义可能导致依赖超时/延迟的算法如限流、租约续期、补偿窗口提前执行四舍五入在精度边界上同样存在提前唤醒的风险向上取整Math.ceil保证唤醒时刻≥ 请求时刻语义最安全且最多引入不到 1 毫秒的额外延迟对定时任务而言可忽略。适用前提与限制该修复作用于集群持久化工作流引擎cluster workflow engineClusterWorkflowEngine.layer需要Sharding.Sharding与MessageStorage服务见 ClusterWorkflowEngine.ts并注册持久化时钟实体Workflow/-/DurableClockDurableClock整体位于effect/unstable/workflow实验性模块API 在 4.0.0 起提供后续仍可能演进内存引擎layerMemory适合测试与本地开发走Effect.delay路径不涉及持久化时间戳因此不受本补丁影响——本补丁仅针对集群持久化路径唤醒时刻归一化只保证投递粒度为整毫秒不改变用户传入的时长本身如10000.5仍被接受也不会改变DurableClock.sleep的公开签名。小结fix-durable-clock-fractional-wakeup这条看似只有一句话的 changeset实际修复的是集群持久化工作流中一条真实存在的精度隐患DurableClock的唤醒消息经由DeliverAt协议进入消息存储层时其投递时刻的粒度是整数毫秒而调用方可能传入分数毫秒时长。通过在scheduleClock中对DateTime.addDuration(now, duration)的结果执行DateTime.mapEpochMillis(..., Math.ceil)effect 将唤醒时刻在源头统一归一化为整毫秒既保证了持久化 SchemaSchema.DateTimeUtcFromMillis与存储字段deliverAt的粒度一致又以向上取整的方式守住了绝不提前唤醒的定时语义。测试用例routes fractional millisecond durable clock wakeups to the workflow shard group给出了10001的精确断言为这一行为提供了可验证的保障。延伸阅读若希望继续深入可对照阅读 DurableClock.ts定时器实现、ClusterWorkflowEngine.ts集群引擎与时钟实体、DeliverAt.ts延迟投递协议以及 ClusterWorkflowEngine.test.ts分数毫秒与零阈值用例。【免费下载链接】effectBuild production-ready applications in TypeScript项目地址: https://gitcode.com/GitHub_Trending/ef/effect创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Effect 4.0 Cluster 持久化工作流DurableClock 唤醒时间戳毫秒级归一化修复解析【免费下载链接】effectBuild production-ready applications in TypeScript项目地址: https://gitcode.com/GitHub_Trending/ef/effect导读本文围绕 effect 仓库中fix-durable-clock-fractional-wakeup这一 changeset 补丁深入剖析集群持久化工作流Cluster Durable Workflow中DurableClock唤醒时间的处理机制。你将了解为什么唤醒时间戳必须归一化为整毫秒、Math.ceil在其中的关键作用、分数毫秒在消息存储与分片路由链路中的潜在风险以及仓库源码与测试用例如何印证这一修复。修复背景一条 changeset 补丁说了什么在 effect 仓库的 .changeset/pre/fix-durable-clock-fractional-wakeup.md 中记录了这样一条针对effect包的补丁--- effect: patch --- Normalize cluster durable clock wake-up timestamps to whole milliseconds.翻译过来即将集群持久化时钟cluster durable clock的唤醒时间戳归一化为整毫秒。这是一条典型的patch级别修复——它不改变任何公开 API 的形状也不引入新特性而是修正了底层持久化时钟唤醒链路中一个潜在的精度隐患。需要强调的是这条 changeset 位于.changeset/pre/目录属于发布前预检pre-release阶段的变更记录。要真正理解这条修复的意义必须回到源码中看清DurableClock的完整数据流。DurableClock持久化工作流中的闹钟模块定位与数据模型DurableClock定义在 packages/effect/src/unstable/workflow/DurableClock.ts位于effect/unstable/workflow模块下入口见 packages/effect/src/unstable/workflow/index.ts从 4.0.0 版本开始提供属于实验性unstableAPI。它解决的问题很直观在可持久化、可重放replay的工作流执行中普通的Effect.sleep会随进程重启而丢失因此需要一个可以被持久化调度、跨进程恢复的定时器。源码头部注释对此有清晰说明Durable timers for workflow sleeps.makecreates aDurableClockwith a name, duration, and deferred wake-up signal.其核心数据结构是一个接口export interface DurableClock { readonly [TypeId]: typeof TypeId readonly name: string readonly duration: Duration.Duration readonly deferred: DurableDeferred.DurableDeferredtypeof Schema.Void }name时钟的名字用于在持久化存储中唯一标识duration休眠时长Duration.Durationdeferred一个关联的DurableDeferred当唤醒时刻到来时被完成从而唤醒正在等待的工作流执行。构造器make的实现见 DurableClock.ts会基于名字创建一个持久化 deferred名字形如DurableClock/${options.name}export const make (options: { readonly name: string readonly duration: Duration.Input }): DurableClock ({ [TypeId]: TypeId, name: options.name, duration: Duration.fromInputUnsafe(options.duration), deferred: DurableDeferred.make(DurableClock/${options.name}) })sleep 的两条路径内存短眠 vs 持久化长眠DurableClock.sleep见 DurableClock.ts是工作流代码中实际调用的入口它的行为遵循一个**内存阈值in-memory threshold**策略export const sleep: ( options: { readonly name: string readonly duration: Duration.Input /** * If the duration is less than or equal to this threshold, the clock will * be executed in memory. * * default 60 seconds */ readonly inMemoryThreshold?: Duration.Input | undefined } ) Effect.Effectvoid, never, WorkflowEngine | WorkflowInstance ...流程分三段零时长短路若duration为零直接返回不做任何调度内存路径若duration inMemoryThreshold默认 60 秒defaultInMemoryThreshold Duration.seconds(60)则通过一个名为DurableClock/${options.name}的 in-memory activity 执行普通Effect.sleep(duration)——此时不需要持久化任何状态持久化路径否则从WorkflowEngine与WorkflowInstance服务中取到当前执行上下文调用engine.scheduleClock(instance.workflow, { executionId, clock })将唤醒计划提交给引擎然后yield* DurableDeferred.await(clock.deferred)等待持久化唤醒信号。需要补充的一点是仓库中另一条 changeset durable-clock-zero-threshold.md 修复了显式传入0/0n作为inMemoryThreshold时被误判为未传参而回退到默认 60 秒的问题。这两条 changeset 都作用于同一模块前者保证0阈值语义正确强制走持久化路径后者则保证持久化路径上的时间戳是干净的整毫秒属于同一子系统内的配套修复。引擎侧的 scheduleClock 契约WorkflowEngine服务在 packages/effect/src/unstable/workflow/WorkflowEngine.ts 中声明了scheduleClock契约/** * Schedule a wake up for a DurableClock */ readonly scheduleClock: ( workflow: Workflow.Any, options: { readonly executionId: string readonly clock: DurableClock } ) Effect.Effectvoid它有两种实现内存引擎layerMemory见 WorkflowEngine.ts直接用Effect.delay(options.clock.duration)配合FiberMap.run实现而集群引擎cluster则把唤醒计划编码为一条持久化消息这正是本次修复的焦点。集群引擎唤醒计划如何变成持久化消息ClockPayload 与 ClockRpc在 packages/effect/src/unstable/cluster/ClusterWorkflowEngine.ts 中持久化时钟被建模为一个独立的集群实体class ClockPayload extends Schema.ClassClockPayload(Workflow/DurableClock/Run)({ name: Schema.String, workflowName: Schema.String, wakeUp: Schema.DateTimeUtcFromMillis }) { [PrimaryKey.symbol]() { return this.name } [DeliverAt.symbol]() { return this.wakeUp } } const ClockRpc Rpc.make(run, { payload: ClockPayload }) .annotate(ClusterSchema.Persisted, true) .annotate(ClusterSchema.Uninterruptible, true) const ClockEntity Entity.make(Workflow/-/DurableClock, [ ClockRpc ])三个字段的语义name时钟名称即DurableClock的name同时作为持久化主键workflowName所属工作流的名称用于唤醒时回填wakeUp绝对唤醒时刻其 Schema 为Schema.DateTimeUtcFromMillis——注意这里是从毫秒解析 UTC 时间即该字段在持久化层的原生粒度就是毫秒实现了DeliverAt协议见 packages/effect/src/unstable/cluster/DeliverAt.ts即这条消息应该被延迟投递到wakeUp时刻。scheduleClock 实现分数毫秒从何而来集群引擎的scheduleClock见 ClusterWorkflowEngine.ts实现如下scheduleClock(workflow, options) { return DateTime.now.pipe( Effect.flatMap((now) sendDiscard({ rpc: ClockRpc, address: entityAddressFor({ workflow, entityType: ClockEntity.type, executionId: options.executionId }), payload: { name: options.clock.name, workflowName: workflow._tag, wakeUp: DateTime.mapEpochMillis( DateTime.addDuration(now, options.clock.duration), Math.ceil ) } }) ), Effect.orDie ) }这里的核心逻辑是wakeUp DateTime.mapEpochMillis( DateTime.addDuration(now, options.clock.duration), Math.ceil )取当前时刻now加上时钟时长得到目标时刻DateTime.addDuration(now, options.clock.duration)用DateTime.mapEpochMillis见 packages/effect/src/DateTime.ts 及其内部实现 packages/effect/src/internal/dateTime.ts对该时刻的epoch 毫秒数应用Math.ceil——即向上取整到下一个整数毫秒。mapEpochMillis的内部实现dateTime.ts本质上是取出toEpochMillis(self)应用映射函数f再按原时区重建 DateTimeexport const mapEpochMillis dual(2, (self, f) { const millis f(toEpochMillis(self)) return self._tag Utc ? makeUtc(millis) : makeZonedProto(millis, self.zone) })那么分数毫秒fractional milliseconds从何而来Duration.Input允许传入10000.5这类带小数的毫秒值测试中就有这样的用例见下文而DateTime内部基于Date/ epoch millis 表示DateTime.addDuration的结果可能携带亚毫秒精度。由于ClockPayload.wakeUp的持久化 Schema 是Schema.DateTimeUtcFromMillis毫秒粒度DeliverAt.toMillis见 DeliverAt.ts取出的是epochMilliseconds分数毫秒若原样进入该字段就会在 Schema 编码 / 解码或存储时被截断truncate或舍入round从而与调用方预期的唤醒时刻产生偏差。Math.ceil的语义是宁可晚唤醒不可早唤醒——提前唤醒对于依赖已等待足够时长语义的定时器而言是更危险的错误。向上取整保证了存储值与语义一致唤醒只可能发生在计划时刻之后绝不会在此之前触发。唤醒消息的完整生命周期从投递到恢复理解了归一化修复之后再沿着数据流看一遍持久化唤醒消息如何最终唤醒工作流能够更清楚地体会这条补丁的价值。延迟投递协议ClockPayload通过DeliverAt协议携带自己的投递时间。消息存储层在扫描待处理消息时会过滤尚未到期的请求见 packages/effect/src/unstable/cluster/MessageStorage.tsif (entry?.deliverAt entry.deliverAt now) { continue // 尚未到投递时刻跳过 }内存驱动的saveEnvelope会把DeliverAt.toMillis(message.envelope.payload)的结果存入条目MessageStorage.tsSQL 驱动的实现则将其作为独立的deliverAt列持久化SqlMessageStorage.ts。这一列/字段的粒度就是毫秒整数因此若wakeUp携带亚毫秒部分无论哪条存储路径都必须做出取舍——这正是归一化必须发生在源头scheduleClock的原因。唤醒实体的处理逻辑持久化时钟实体ClockEntity的处理器ClusterWorkflowEngine.ts在消息到达后执行return { run(request) { const deferred DurableClock.make({ name: request.payload.name, duration: Duration.zero }).deferred return ensureSuccess(engine.deferredDone(deferred, { workflowName: request.payload.workflowName, executionId, deferredName: deferred.name, exit: Exit.void })) } }它用消息中携带的name重建同名 deferred并以Exit.void完成它——这正是工作流中DurableDeferred.await(clock.deferred)等待的信号。engine.deferredDone随后会把完成结果持久化并恢复resume挂起的工作流执行使其从上次休眠处继续运行完整逻辑见 WorkflowEngine.ts。整个链路可概括为DurableClock.sleep(duration) └─ engine.scheduleClock() [当前时刻 durationMath.ceil 归一整毫秒] └─ ClockRpc 消息写入 MessageStoragedeliverAt wakeUp 毫秒 └─ 存储层按 deliverAt 延迟投递 └─ ClockEntity 处理器完成持久化 deferred └─ 工作流执行恢复sleep 返回测试印证整毫秒断言与分数毫秒用例仓库测试给出了这条修复的直接证据。在 packages/effect/test/cluster/ClusterWorkflowEngine.test.ts 中有一个名为routes fractional millisecond durable clock wakeups to the workflow shard group的用例专门针对分数毫秒唤醒时间it.effect(routes fractional millisecond durable clock wakeups to the workflow shard group, () Effect.gen(function*() { const driver yield* MessageStorage.MemoryDriver const sharding yield* Sharding.Sharding const scheduled yield* ShardedClockScheduled const startedAt yield* DateTime.now const fiber yield* ShardedClockWorkflow.execute({ id: sharded-clock }) .pipe(Effect.forkChild({ startImmediately: true })) yield* scheduled.await const envelope driver.journal.find((envelope) envelope._tag Request envelope.address.entityType Workflow/-/DurableClock ) assert(envelope) assert.strictEqual(envelope.address.shardId.group, workflow) const deliverAt driver.requests.get(envelope.requestId)?.deliverAt assert.isNumber(deliverAt) assert.strictEqual(deliverAt, DateTime.toEpochMillis(startedAt) 10001) yield* TestClock.adjust(10001) ... }))该用例对应的被测工作流ClusterWorkflowEngine.test.ts故意使用了分数毫秒时长const clock DurableClock.make({ name: ShardedClock, duration: 10000.5 // 10 秒 0.5 毫秒 }) yield* engine.scheduleClock(instance.workflow, { executionId: instance.executionId, clock })注意这里的断言assert.strictEqual(deliverAt, DateTime.toEpochMillis(startedAt) 10001)startedAt整数毫秒加上10000.5本应产生小数但断言期望的是10001——即Math.ceil向上取整后的结果。这个用例同时验证了两件事归一化生效deliverAt是整毫秒且等于起始时刻 时长向上取整分片路由正确消息被路由到shardId.group workflow的 shard group该工作流通过ClusterSchema.ShardGroup注解指定见 ClusterWorkflowEngine.test.ts。此外同文件中的零阈值用例ClusterWorkflowEngine.test.ts通过注入makeWorkflowEngineUnsafe假引擎验证了显式0/0n阈值时DurableClock.sleep只调用scheduleClock与deferredResult而不经过内存 activity——印证了前面提到的配套补丁。修复价值与边界说明为什么必须向上取整而不是截断或四舍五入对定时唤醒语义而言早唤醒比晚唤醒更危险若截断Math.floor/ 隐式toMillis截断工作流可能在目标时刻之前被唤醒破坏至少休眠 N 时长的语义可能导致依赖超时/延迟的算法如限流、租约续期、补偿窗口提前执行四舍五入在精度边界上同样存在提前唤醒的风险向上取整Math.ceil保证唤醒时刻≥ 请求时刻语义最安全且最多引入不到 1 毫秒的额外延迟对定时任务而言可忽略。适用前提与限制该修复作用于集群持久化工作流引擎cluster workflow engineClusterWorkflowEngine.layer需要Sharding.Sharding与MessageStorage服务见 ClusterWorkflowEngine.ts并注册持久化时钟实体Workflow/-/DurableClockDurableClock整体位于effect/unstable/workflow实验性模块API 在 4.0.0 起提供后续仍可能演进内存引擎layerMemory适合测试与本地开发走Effect.delay路径不涉及持久化时间戳因此不受本补丁影响——本补丁仅针对集群持久化路径唤醒时刻归一化只保证投递粒度为整毫秒不改变用户传入的时长本身如10000.5仍被接受也不会改变DurableClock.sleep的公开签名。小结fix-durable-clock-fractional-wakeup这条看似只有一句话的 changeset实际修复的是集群持久化工作流中一条真实存在的精度隐患DurableClock的唤醒消息经由DeliverAt协议进入消息存储层时其投递时刻的粒度是整数毫秒而调用方可能传入分数毫秒时长。通过在scheduleClock中对DateTime.addDuration(now, duration)的结果执行DateTime.mapEpochMillis(..., Math.ceil)effect 将唤醒时刻在源头统一归一化为整毫秒既保证了持久化 SchemaSchema.DateTimeUtcFromMillis与存储字段deliverAt的粒度一致又以向上取整的方式守住了绝不提前唤醒的定时语义。测试用例routes fractional millisecond durable clock wakeups to the workflow shard group给出了10001的精确断言为这一行为提供了可验证的保障。延伸阅读若希望继续深入可对照阅读 DurableClock.ts定时器实现、ClusterWorkflowEngine.ts集群引擎与时钟实体、DeliverAt.ts延迟投递协议以及 ClusterWorkflowEngine.test.ts分数毫秒与零阈值用例。【免费下载链接】effectBuild production-ready applications in TypeScript项目地址: https://gitcode.com/GitHub_Trending/ef/effect创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
