Skip to content

Schedule

pawaca edited this page Aug 30, 2026 · 2 revisions

Schedule

Edge adaptation status of the upstream persistent reminder system.

Upstream reference: Schedule

What Upstream Provides

The Schedule subsystem provides persistent reminders delivered within live sessions as normal follow-up conversation turns. Three reminder types:

  • After — delayed one-shot reminders (e.g. "remind me in 30 minutes")
  • At — absolute-time one-shot reminders with timezone-aware parsing (RFC 3339 or local calendar input, DST gap/overlap handling)
  • Every — fixed-rate recurring reminders (minimum 5-minute interval)

All reminders are event-sourced: schedule/change events (create, delete, dispatch) persist in the session log. The in-process owner manages timers from the persisted state. Delivery is session-local only — no external notification channels. One-shot reminders get priority; multiple expired recurring reminders batch into a single follow-up turn.

Current Edge Status

Not implemented. No schedule-related packages are installed. The upstream dsh-schedule package is not in Edge's dependencies.

Cloudflare Enablers

The primary building block already exists in Edge: Durable Object alarms. Edge currently uses ctx.storage.setAlarm() for WebSocket downlink expiry management. The same mechanism could power scheduled reminders.

Enabler Plan Feasibility Notes
DO alarms Free High Already used by Edge for downlink expiry. One alarm per DO — would need multiplexing (earliest-wins scheduling, re-arm after each fire).
Cron Triggers Free Medium Global Worker-level cron, not per-session. Could poll DOs for due reminders, but adds latency and complexity.
Queues Paid Low Message queues with delayed delivery. Over-engineered for session-local reminders.

Integration path

The most natural approach: install the upstream Schedule service and replace its in-process timer with a DO alarm adapter. The upstream service already handles event sourcing, timezone parsing, and DST — only the timer backend needs replacement. The DO alarm would fire at the earliest pending reminder time, the handler would dispatch due reminders via agent.followup(), then re-arm for the next one.

Key constraint: DOs support only one alarm at a time. The adapter must maintain a sorted list of pending reminders and always set the alarm to the earliest. This is the same earliest-wins pattern Edge already uses for downlink expiry.

Architecture Summary

Component Status Enabler
Schedule service (event sourcing, timezone, types) 🚫 Not installed Upstream plugin — likely direct reuse
Timer backend 🚫 Not implemented DO alarm adapter (free plan)
Reminder delivery 🚫 Not implemented agent.followup() — same as GoalRoundDriver

TODO

(#110) Evaluate upstream Schedule service installation. Check inject requirements. The service needs a timer backend — evaluate whether a DO alarm adapter can satisfy the upstream interface. Reminder delivery via agent.followup() follows the same pattern as GoalRoundDriver. All functionality could work on the free plan.

English

中文

Clone this wiki locally