Recurring Tasks via Self-Scheduling in Effect

SkillProductivity

Lets your agent run tasks on a schedule, like periodic jobs, retries with backoff, cleanups, and heartbeat checks.

Use Recurring Tasks via Self-Scheduling in Effect in Claude, ChatGPT or Ahel Desktop

Free. Sign in, add Recurring Tasks via Self-Scheduling in Effect and connect your AI. About a minute.

Also: Claude Code · Cursor · Codex

Then ask your AI: use the Recurring Tasks via Self-Scheduling in Effect skill

Details

Instructions available. Your AI can read the instructions. Execution depends on the setup they require.

Add ahel to your AI once: Claude, ChatGPT, Cursor, Claude Code or Codex. Then ask it to use this.

Recurring Tasks via Self-Scheduling in EffectStart free
About this skill

Implementing durable recurring, cron-like, polling, cleanup, and heartbeat tasks by self-scheduling Effect Golem agent methods. Use for periodic jobs, exponential backoff, cancelable schedules, or self-scheduling agents with @golemcloud/effect-golem.

What this skill tells your AI

The instructions your AI receives, as published by golemcloud/golem in golem-skills/skills/effect/golem-recurring-task-effect/SKILL.md and read by ahel’s review.

An Effect Golem agent can schedule a future invocation of one of its own methods after each run. The scheduled invocation is durable and survives agent suspension or recovery; the agent does not need an in-process timer, sleeping fiber, or external cron service.

The Scheduling API

Obtain a typed client for the same durable identity, then yield the remote method's .schedule(scheduledAt, input) Effect:

const self = yield * PollerDefinition.client.get({ name });
const scheduled = yield * self.poll.schedule(scheduledAt, {});

The pinned Effect SDK has these exact semantics:

  • client.get(...) takes the complete named constructor-parameter record.
  • A method with input: {} still receives {} in remote calls.
  • .schedule(at, input) expects a WIT wall-clock value with { seconds: bigint, nanoseconds: number }.
  • .schedule(...) is already cancelable and returns Client.ScheduledInvocation.
  • Cancel with yield* scheduled.cancel(). There is no .scheduleCancelable() method.
  • Dropping or losing the returned handle does not cancel the invocation; only calling cancel() does.
  • Both client.get(...) and .schedule(...) are lazy Effects and must be yielded.

Construct the WIT datetime explicitly. Convert Effect's DateTime.Utc with DateTime.toEpochMillis(...); the DateTime value is not itself the { seconds, nanoseconds } record required by .schedule(...):

const now = yield * DateTime.now;
const atMillis = DateTime.toEpochMillis(now) + delaySeconds * 1_000;
const scheduledAt = {
  seconds: BigInt(Math.floor(atMillis / 1_000)),
  nanoseconds: Math.floor(atMillis % 1_000) * 1_000_000,
};

Do not pass Date.now() + delay, an ISO string, or DateTime.toUtc(...) directly to the typed client.

Complete Cancelable Ticker

This example starts immediately, schedules each later tick five seconds ahead, and retains the live cancellation handle for the next invocation:

import { DateTime, Effect, Ref, Schema } from "effect";
import { type Client, defineAgent, method } from "@golemcloud/effect-golem";

const TickerDefinition = defineAgent({
  name: "Ticker",
  mode: "durable",
  id: {
    name: Schema.String,
  },
  methods: {
    start: method({ input: {}, success: Schema.Void }),
    tick: method({ input: {}, success: Schema.Void }),
    cancel: method({ input: {}, success: Schema.Void }),
    getTickCount: method({ input: {}, success: Schema.Number }),
  },
});

export const Ticker = TickerDefinition.implement({
  init: ({ name }) =>
    Effect.gen(function* () {
    const state = yield* Ref.make({ tickCount: 0, running: false });
    const pending = yield* Ref.make<Client.ScheduledInvocation | null>(null);
    return { name, state, pending };
  }),
  methods: ({ name, state, pending }) => {

    const scheduleNext = (delaySeconds: number) =>
      Effect.gen(function* () {
        const now = yield* DateTime.now;
        const atMillis = DateTime.toEpochMillis(now) + delaySeconds * 1_000;
        const scheduledAt = {
          seconds: BigInt(Math.floor(atMillis / 1_000)),
          nanoseconds: Math.floor(atMillis % 1_000) * 1_000_000,
        };

        const self = yield* TickerDefinition.client.get({ name });
        const scheduled = yield* self.tick.schedule(scheduledAt, {});
        yield* Ref.set(pending, scheduled);
      });

    const tick = Effect.gen(function* () {
      // A handle for an invocation that is already running is no longer useful.
      yield* Ref.set(pending, null);

      const current = yield* Ref.get(state);
      if (!current.running) return;

      const tickCount = current.tickCount + 1;
      yield* Ref.set(state, { ...current, tickCount });

      if (tickCount < 5) {
        yield* scheduleNext(5);
      }
    }).pipe(Effect.orDie);

    return {
      start: () =>
        Effect.gen(function* () {
          const current = yield* Ref.get(state);
          if (current.running) return;
          yield* Ref.set(state, { ...current, running: true });
          yield* tick;
        }),

      tick: () => tick,

      cancel: () =>
        Effect.gen(function* () {
          const current = yield* Ref.get(state);
          yield* Ref.set(state, { ...current, running: false });

          const scheduled = yield* Ref.get(pending);
          yield* Ref.set(pending, null);
          if (scheduled !== null) {
            yield* scheduled.cancel();
          }
        }),

      getTickCount: () =>
        Ref.get(state).pipe(Effect.map(({ tickCount }) => tickCount)),
    };
  },
});

Register the implementation from the component entry point:

// src/main.ts
import "./ticker.js";

client.get(...) and .schedule(...) can fail with SDK infrastructure errors. The example uses Effect.orDie around the recurring tick because its public method declares no typed error. If callers should handle scheduling failures, map them to a domain error declared in the method's error schema instead.

Logical Stop Versus Exact Cancellation

For the simplest recovery-safe stop operation, store a boolean or generation number in normal agent state:

poll: () =>
  Effect.gen(function* () {
    const { running } = yield* Ref.get(state);
    if (!running) return;
    yield* doWork;
    yield* scheduleNext(60);
  }).pipe(Effect.orDie),

stop: () => Ref.update(state, (current) => ({ ...current, running: false })),

The already-scheduled invocation still arrives, observes running === false, and becomes a no-op. This is usually enough and requires no cancellation handle.

Use Client.ScheduledInvocation only when the pending invocation must be dropped immediately. It wraps a live host resource and may be kept in an ordinary Ref, but it is not schema-serializable:

  • do not include it in Snapshot.define(...) state;
  • the SDK exposes no token ID, decoder, or reopen operation after snapshot restore or component recreation;
  • keep the durable running flag, generation, interval, and next intended time separately;
  • design a restored agent so a stale invocation can safely run and exit, rather than promising that its old cancellation handle can be recovered.

Exponential Backoff

Persist the consecutive failure count and derive the next delay after each attempt:

const delaySeconds = success
  ? baseIntervalSeconds
  : Math.min(
      baseIntervalSeconds * 2 ** Math.min(consecutiveFailures, 6),
      maxIntervalSeconds,
    );

yield * scheduleNext(delaySeconds);

Reset consecutiveFailures to zero on success and increment it before computing a failed attempt's delay. Keep the cap so an unavailable dependency does not make the recurrence disappear for an unexpectedly long time.

Operational Constraints

  • Agent invocations are sequential, so two methods on the same agent do not mutate recurrence state concurrently.
  • Keep the scheduled method idempotent because durable recovery can retry an invocation.
  • Schedule the next occurrence after the current work finishes. Scheduling first can create overlapping intent if the current work fails and retries.
  • Treat the scheduled datetime as a lower bound, not an exact timer. The host scheduler polls for due work, and the invocation may also wait behind queued work on the same agent. Tests should poll observable state or allow scheduler latency beyond the requested delay.
  • Repeated start calls must not create parallel scheduling chains; check the running state first.
  • Each tick grows the durable agent's oplog. For frequent or long-running recurrences, use golem-custom-snapshot-effect and snapshot only schema-serializable logical state.
  • Use Effect HTTP route metadata when a poll count or status must be observable over HTTP; the self-scheduling client API remains the same.

CLI Scheduling and Cancellation

CLI method names and values use TypeScript casing and syntax for Effect applications. An explicit idempotency key can identify a CLI-scheduled invocation for later cancellation:

golem agent invoke --trigger --schedule-at 2026-03-15T10:30:00Z -i 'poll-next' \
  'PollerAgent("my-poller")' poll

golem agent cancel-invocation 'PollerAgent("my-poller")' 'poll-next'

Signals

GitHub stars
2k
Forks
210
Last commit
Oct 2026
Advanced
Item type
skill
Key
golem-recurring-task-effect
Source
github.com/golemcloud/golem