The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
agents-api	Ready	Preview, Comment	Mar 30, 2026 7:49pm
agents-manage-ui	Ready	Preview, Comment	Mar 30, 2026 7:49pm

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
agents-docs	Skipped		Mar 30, 2026 7:49pm

🦋 Changeset detected

Latest commit: 4172a80

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

TL;DR — Replaces the per-trigger daisy-chaining workflow architecture for scheduled triggers with a single centralized table-driven scheduler. A long-lived schedulerWorkflow ticks every 60 seconds, queries a next_run_at column for due triggers, and dispatches one-shot execution workflows. The scheduled_triggers table moves from the manage DB (Doltgres) to the runtime DB (Postgres), eliminating branch-scoped queries in the hot path. Scheduled triggers are removed as a first-class concept from the SDK and CLI — they are now managed exclusively through the API/UI. The ScheduledWorkflow entity and all per-trigger workflow lifecycle management are deleted.

Key changes

• Centralized scheduler workflow — A singleton schedulerWorkflow ticks every 60 seconds, queries all due triggers across projects via findDueScheduledTriggersAcrossProjects, and dispatches independent one-shot execution workflows instead of each trigger managing its own long-lived daisy-chained workflow.
• Schema migration: manage → runtime — scheduled_triggers is unexported from the manage schema and recreated in the runtime DB with new next_run_at, ref columns and three indexes. scheduled_workflows table is dropped entirely. A new scheduler_state singleton table tracks the active scheduler run ID.
• Simplified trigger runner — The scheduledTriggerRunner shrinks from a ~500-line daisy-chaining state machine to a ~180-line one-shot workflow with no sleep-until-scheduled, no adoption logic, and no self-chaining. Retry backoff changes from linear to exponential (retryDelaySeconds * 2^(attemptNumber-1) * (1 + jitter)).
• SDK and CLI removal — The ScheduledTrigger class, scheduledTrigger() builder function, and all SDK types are deleted. CLI pull-v4 code generation for scheduled triggers is removed entirely. Triggers are no longer a versioned config concept managed alongside agent definitions.
• DAL layer migration — All scheduled trigger CRUD moves from manage/scheduledTriggers.ts to runtime/scheduledTriggers.ts with new queries for due-trigger dispatch, next_run_at advancement, and ref-scoped deletion. upsertScheduledTrigger auto-computes nextRunAt before writing.
• ScheduledTriggerService gutted — Shrinks from ~340 lines to ~70. Only onTriggerUpdated remains for stale invocation cleanup. onTriggerCreated, onTriggerDeleted, and all workflow start/stop/restart functions are removed.
• Full agent definition decoupled — getFullAgentDefinitionInternal, createFullAgentServerSide, and updateFullAgentServerSide no longer read, create, or sync scheduled triggers. The agentFull and projectFull routes pass runDbClient for cross-DB trigger operations via separate upsert calls.
• Cascade delete extended — cascadeDeleteByBranch (now accepting a ref parameter), cascadeDeleteByProject, and cascadeDeleteByAgent now explicitly delete scheduledTriggers from the runtime DB. Branch-scoped trigger cleanup is handled directly within cascadeDeleteByBranch.
• Deploy restart hook — A POST /api/deploy/restart-scheduler endpoint with constant-time bearer auth, plus a new CI job in vercel-production.yml, restarts the scheduler on each production deploy.
• Branch ref support — New ref column on triggers enables per-branch agent execution. The ref flows from trigger config through TriggerPayload to executeScheduledTriggerStep where it resolves to a project-scoped ref. UI shows a "Branch" column and branch selector in the trigger form.
• Manual execution resolves ref from trigger — Rerun and manual-run routes now resolve ref from the trigger's stored ref column via resolveRef(manageDbClient) instead of reading the request middleware's resolvedRef, with validation for missing or unresolvable refs.
• computeNextRunAt extracted to core — Pure utility in agents-core/src/utils/ computing next cron/runAt timestamps, used by both route handlers (create/update) and the dispatcher.
• Data migration script — A migrate-triggers-to-runtime.ts script copies existing triggers from Doltgres branches to Postgres, computing nextRunAt for each enabled trigger. Supports dry-run by default with --apply flag.
• Scope helpers inlined — The runtime DAL replaces abstract agentScopedWhere/projectScopedWhere helpers with explicit eq() chains for all runtime-side queries.
• Reconciliation cleanup — scheduled_triggers handler deleted entirely from reconciliation registry; reconciliation tests rewritten to use generic entity names (agent, tools) instead of scheduled_triggers.
• UI triggers table rewrite — Rebuilt with raw Table components, adds "Branch" column with GitBranch icon and "Next Run" column displaying nextRunAt. Manual trigger execution gains a double-click guard. Trigger form adds an "Agent Version" card with a branch selector via useBranches hook.
• ScheduledWorkflow entity removed — Table, schema, relations, validation schemas, DAL, and all references deleted.
• Type exports moved to entities.ts — ScheduledTrigger, ScheduledTriggerInvocation, and SchedulerState type aliases moved from schemas.ts to entities.ts for consistency with other entity types.
• Test coverage — 5 new test suites covering SchedulerService, triggerDispatcher (fault tolerance, ordering, ref passthrough), scheduledTriggerSteps, schedulerSteps, and cascade delete with scheduledTriggers. CRUD tests add resolveRef mocks and seedTestUser helpers for branch resolution and user FK constraints.

_{Summary ｜ 74 files ｜ 62 commits ｜ base: main ← feat/manage-table-cron-dispatcher-v3}

Schema migration: scheduled_triggers moves to runtime DB

Before: scheduled_triggers and scheduled_workflows tables lived in the manage DB (Doltgres) and required withRef / AS OF branch-scoped queries for every read.
After: scheduled_triggers is a new table in the runtime DB (Postgres) with next_run_at, ref, and three indexes. scheduled_workflows is deleted entirely. A scheduler_state singleton table tracks the active scheduler run ID. The manage-side scheduledTriggers table definition is unexported (changed from export const to const) and its relations are renamed to _scheduledTriggersRelations to prevent external usage while preserving Drizzle's internal relation resolution.

The runtime schema gains scheduledTriggers with a (tenant_id, id) composite PK (simplified from the old manage table's 4-column PK), next_run_at (indexed alongside enabled for the dispatch query), ref (indexed for branch deletion cleanup), and an agent composite index. Column types change from numeric to integer for retry/timeout fields. The scheduler_state table stores a single row via a SINGLETON_ID = 'singleton' pattern.

manage-schema.ts · runtime-schema.ts · 0028_thick_squirrel_girl.sql

Centralized scheduler workflow

Before: Each enabled trigger had its own long-lived workflow that calculated next execution time, slept until then, executed, and daisy-chained to a new workflow for the next iteration.
After: A single schedulerWorkflow wakes every 60 seconds, queries scheduled_triggers WHERE enabled AND next_run_at <= now(), and dispatches independent one-shot scheduledTriggerRunnerWorkflow instances.

The schedulerWorkflow registers its run ID in scheduler_state, then loops: sleep until the next minute boundary, verify it hasn't been superseded, and call dispatchDueTriggers(). The triggerDispatcher queries due triggers, starts a workflow per trigger via Promise.allSettled (fault-tolerant — individual failures don't block others), and advances next_run_at (or disables one-time triggers). The SchedulerService class wraps workflow start/stop as a thin service-level API.

How does supersession work across deploys?

Each scheduler instance writes its runId to scheduler_state on startup. On every tick, it reads the current runId and exits if it no longer matches — ensuring only one scheduler is active at a time. On production deploys, the CI workflow calls POST /api/deploy/restart-scheduler to start a new scheduler that supersedes the old one.

schedulerWorkflow.ts · triggerDispatcher.ts · schedulerSteps.ts · SchedulerService.ts

Simplified trigger runner (one-shot execution)

Before: A ~500-line workflow handling next-execution calculation, sleep-until-due, pre/post-sleep enabled checks, daisy-chain startup, parent run ID adoption, and complex cancelled-invocation recovery paths.
After: A ~180-line one-shot workflow that checks if the trigger is enabled, creates an idempotent invocation, runs the agent with retries, and returns completed/failed/cancelled.

The workflow payload changes from ScheduledTriggerRunnerPayload (with lastScheduledFor, parentRunId) to TriggerPayload (with scheduledFor, ref). All steps for calculateNextExecutionStep, computeSleepDurationStep, getNextPendingInvocationStep, deletePendingInvocationsStep, and startNextIterationStep are removed. The retry strategy changes from linear to exponential backoff: retryDelaySeconds * 2^(attemptNumber-1) * (1 + jitter). One-time triggers are disabled via a new disableOneTimeTriggerStep on success or failure.

scheduledTriggerRunner.ts · scheduledTriggerSteps.ts

SDK and CLI scheduled trigger removal

Before: Scheduled triggers were a first-class SDK concept — the ScheduledTrigger class, scheduledTrigger() builder, and AgentConfig.scheduledTriggers let users define triggers programmatically. CLI pull-v4 generated trigger code as part of agent definitions.
After: All SDK types (ScheduledTrigger, ScheduledTriggerConfig, ScheduledTriggerInterface), builder functions, and Agent class integration are deleted. CLI code generation for scheduledTriggers is removed from generators, helpers, component registry, and test snapshots.

Triggers are no longer a versioned configuration concept managed alongside agent definitions. They are exclusively a runtime scheduling record managed through the API and UI. The Agent class no longer has getScheduledTriggers(), addScheduledTrigger(), or scheduledTriggers in its serialized output. getFullAgentDefinitionInternal no longer fetches triggers from the manage DB. createFullAgentServerSide and updateFullAgentServerSide no longer create or sync triggers.

scheduled-trigger.ts · agent.ts · builderFunctions.ts · scheduled-trigger-generator.ts

Route and service layer changes

Before: All scheduled trigger CRUD routes used c.get('db') (branch-scoped manage DB) and called onTriggerCreated / onTriggerDeleted / onTriggerUpdated to start/stop/restart per-trigger workflows. Manual execution routes read ref from the request middleware's resolvedRef.
After: Routes use runDbClient directly, compute nextRunAt inline via computeNextRunAt() on create/update, and only call onTriggerUpdated for invocation cleanup on re-enable or schedule change. Manual execution (rerun and manual-run) resolves ref from the trigger's stored ref column via resolveRef(manageDbClient) with validation for missing or unresolvable refs.

The ScheduledTriggerService shrinks from ~340 lines to ~70, retaining only onTriggerUpdated for cancelling stale invocations. The agentFull.ts and projectFull.ts routes now accept an optional runDbClient parameter to handle cross-DB trigger operations, and use upsertScheduledTrigger (which auto-computes nextRunAt) for trigger syncing. CRUD tests add resolveRef mocks to handle branch resolution in the test environment and seedTestUser helpers for user FK constraints.

scheduledTriggers.ts · ScheduledTriggerService.ts · agentFull.ts · projectFull.ts

Data access layer migration and cascade deletes

Before: Scheduled trigger CRUD lived in data-access/manage/scheduledTriggers.ts targeting the manage DB, with a separate scheduledWorkflows.ts. Cascade deletes did not cover triggers in the runtime DB.
After: A new data-access/runtime/scheduledTriggers.ts provides all CRUD plus findDueScheduledTriggersAcrossProjects, advanceScheduledTriggerNextRunAt, upsertScheduledTrigger, and deleteScheduledTriggersByRunAsUserId. Cascade deletes gain a scheduledTriggersDeleted field.

The manage-side scheduledTriggers.ts and scheduledWorkflows.ts are deleted. cascadeDeleteByBranch now accepts a ref parameter and directly deletes triggers matching that ref. cascadeDeleteByProject and cascadeDeleteByAgent similarly delete scheduledTriggers from the runtime DB. The triggerCleanup.ts utility moves deleteScheduledTriggersByRunAsUserId calls from the manage-DB branch-scoped path to a direct runtime-DB path using Promise.allSettled across projects.

runtime/scheduledTriggers.ts · runtime/schedulerState.ts · cascade-delete.ts · branches.ts

Deploy restart and startup integration

Before: Each trigger's workflow was individually managed; Vercel deploys could leave orphaned workflows on old instances.
After: On startup (postgres/local), startSchedulerWorkflow() is called after orphan recovery. On Vercel, a CI step calls POST /api/deploy/restart-scheduler (authenticated via INKEEP_AGENTS_RUN_API_BYPASS_SECRET) to start a new scheduler that supersedes the old one.

The restartScheduler.ts route uses constant-time comparison (SHA-256 + timingSafeEqual) for the bearer token. The vercel-production.yml workflow adds a restart-scheduler job that runs after promote + deploy-agents-api with retry logic (3 retries, 5s delay). The route is mounted before auth middleware in createApp.ts.

restartScheduler.ts · createApp.ts · index.ts · vercel-production.yml

Branch ref support, computeNextRunAt, and data migration

Before: Triggers always ran against the default branch. nextRunAt was computed inside the per-trigger workflow at runtime. No migration tooling existed for the manage→runtime transition.
After: A ref column (default 'main', max 256 chars) enables per-branch agent execution. computeNextRunAt is a pure utility in agents-core/src/utils/ used by route handlers, the runtime DAL upsert, and the dispatcher. A migration script bridges existing Doltgres data to Postgres.

Route handlers and upsertScheduledTrigger compute nextRunAt eagerly before writing to the DB. The triggerDispatcher calls computeNextRunAt after each successful dispatch to advance to the next scheduled time. The utility handles cron expressions (via cron-parser, now a dependency of agents-core), one-time runAt timestamps, and timezone-aware scheduling. The migrate-triggers-to-runtime.ts script iterates all Doltgres branches, reads triggers with AS OF '<branch>', extracts ref from branch naming conventions, computes nextRunAt, and upserts into the runtime table. It defaults to dry-run and requires --apply to commit changes.

compute-next-run-at.ts · migrate-triggers-to-runtime.ts · triggerDispatcher.test.ts

Validation and reconciliation cleanup

Before: Validation schemas included ScheduledWorkflow* types. Reconciliation registry had a scheduled_triggers entity handler that cross-referenced workflows against triggers. Type aliases for scheduled entities were co-located in schemas.ts.
After: All ScheduledWorkflow schemas/types removed. scheduled_triggers handler deleted entirely from the reconciliation registry. Type aliases (ScheduledTrigger, ScheduledTriggerInvocation, SchedulerState) moved to entities.ts. Column types for maxRetries, retryDelaySeconds, and timeoutSeconds change from number to integer (int32) in the OpenAPI spec.

ScheduledTriggerInsertSchema now omits nextRunAt and extends payload with an explicit z.record() type. ScheduledTriggerUpdateSchema gains a ref field. The AgentWithinContextOfProjectSchemaBase removes scheduledTriggers from its field map. The AgentWithinContextOfProjectSelectSchema drops scheduledTriggers from its required fields. The OpenAPI snapshot removes ScheduledTriggerInsertBase and ScheduledWorkflow* schemas, adds ref and nextRunAt to ScheduledTrigger, and adds the POST /api/deploy/restart-scheduler endpoint.

schemas.ts · registry.ts · scheduled-triggers.ts · entities.ts

UI: triggers table rewrite with branch selector

Before: The triggers table used DataTable with ColumnDef, useMemo, useCallback, and useEffect. No branch information was shown. Trigger form had no branch field.
After: The table is rebuilt with raw Table components, adds a "Branch" column with GitBranch icon and a "Next Run" column displaying nextRunAt. The trigger form gains an "Agent Version" card with a branch selector powered by a new useBranches hook. Manual trigger execution has a double-click guard to prevent duplicate dispatches while a run is in flight.

project-scheduled-triggers-table.tsx · scheduled-trigger-form.tsx · use-branches.ts · branches.ts

  ^{｜ View workflow run ｜ Triggered by Pullfrog ｜ Using Claude Opus ｜ 𝕏}

Ito Test Report ❌

16 test cases ran. 2 failed, 14 passed.

Across 16 scheduled-trigger and scheduler API/UI tests, 14 passed and validated core behavior including correct branch handling (recurring refs and one-time default to main), in-place edit updates without duplication, normal Run Now execution, enable/disable next-run recomputation with rapid-toggle state persistence, restart-scheduler auth and metadata responses (200 for valid, 401 for invalid), branch-deletion resilience (cleanup, safe deep-links, stale-tab rejection), stable nextRunAt rendering, runAsUserId validation, and XSS-safe rendering. The two medium, code-supported regressions were that rapid double-clicking Run Now can deterministically create duplicate invocations (no UI re-entry guard plus timestamp-based idempotency key) and ref-only PATCH updates are incorrectly rejected as “No fields to update” because the update-field guard omits ref even though the schema/write path supports it, with both issues tied to code changed in this PR.

❌ Failed (2)

Category	Summary	Screenshot
Edge	🟠 Rapid Run Now double-click creates duplicate invocations for one intended manual run.
Logic	🟠 Ref-only PATCH requests are rejected as "No fields to update" even though ref is a valid updatable field.

const runTrigger = async (triggerId: string, agentId: string, name: string) => {
  setLoadingTriggers((prev) => new Set(prev).add(triggerId));

  try {
    const result = await runScheduledTriggerNowAction(tenantId, projectId, agentId, triggerId);
    if (result.success) {
      toast.success(`Scheduled trigger \"${name}\" started`);
      router.refresh();
    } else {
      toast.error(result.error);
    }

{canManage && (
  <DropdownMenuItem
    onClick={() => runTrigger(trigger.id, trigger.agentId, trigger.name)}
  >
    <Play className="w-4 h-4" />
    Run Now
  </DropdownMenuItem>
)}

await createScheduledTriggerInvocation(runDbClient)({
  id: invocationId,
  tenantId,
  projectId,
  agentId,
  scheduledTriggerId,
  ref: resolvedRef,
  status: 'pending',
  scheduledFor: new Date().toISOString(),
  idempotencyKey: `manual-run-${scheduledTriggerId}-${Date.now()}`,
  attemptNumber: 1,
});

idempotencyKey: varchar('idempotency_key', { length: 256 }).notNull(),
createdAt: timestamp('created_at', { withTimezone: true, mode: 'string' })
  .notNull()
  .defaultNow(),
},
(table) => [
  primaryKey({ columns: [table.tenantId, table.id] }),
  uniqueIndex('sched_invocations_idempotency_idx').on(table.idempotencyKey),
]

// Check if any update fields were actually provided
const hasUpdateFields =
  body.name !== undefined ||
  body.description !== undefined ||
  body.enabled !== undefined ||
  body.cronExpression !== undefined ||
  body.cronTimezone !== undefined ||
  body.runAt !== undefined ||
  body.payload !== undefined ||
  body.messageTemplate !== undefined ||
  body.maxRetries !== undefined ||
  body.retryDelaySeconds !== undefined ||
  body.timeoutSeconds !== undefined ||
  body.runAsUserId !== undefined;

const updatedTrigger = await updateScheduledTrigger(runDbClient)({
  scopes: { tenantId, projectId, agentId },
  scheduledTriggerId: id,
  data: {
    ...body,
    maxRetries: resolveRetryValue(body.maxRetries, existing.maxRetries, 3),
    retryDelaySeconds: resolveRetryValue(body.retryDelaySeconds, existing.retryDelaySeconds, 60),
    timeoutSeconds: resolveRetryValue(body.timeoutSeconds, existing.timeoutSeconds, 300),
    runAsUserId,
    ...(nextRunAt !== undefined ? { nextRunAt } : {}),
  },
});

export const ScheduledTriggerUpdateSchema = ScheduledTriggerInsertSchemaBase.extend({
  enabled: z.boolean().optional().describe('Whether the trigger is enabled'),
  cronTimezone: z.string().max(64).nullable().optional(),
  maxRetries: z.number().int().min(0).max(10).optional(),
  retryDelaySeconds: z.number().int().min(10).max(3600).optional(),
  timeoutSeconds: z.number().int().min(30).max(780).optional(),
}).partial();

✅ Passed (14)

Category	Summary	Screenshot
Adversarial	Forbidden runAsUserId values (system, apikey:*) were rejected on create and patch with HTTP 400 responses.
Adversarial	XSS-like strings in trigger fields rendered safely in table, edit, and invocations views; no script execution observed.
Adversarial	Unauthorized restart requests (missing auth, wrong token, malformed bearer prefix) all returned 401.
Adversarial	Stale-tab update after deletion returned not-found behavior and did not recreate the trigger.
Edge	Five rapid toggle clicks persisted the final Disabled state after polling and reload.
Edge	Deep-link to a deleted trigger did not show an editable stale form.
Logic	Disable cleared next run and re-enable recomputed a future next-run timestamp.
Logic	Fresh enabled recurring trigger kept a non-null nextRunAt and a visible Next Run value after reload.
Happy-path	Recurring trigger creation with ref=feature/test-branch succeeded on API re-check; prior failure was environment-related, not route logic.
Happy-path	One-time trigger creation succeeded with default main branch and expected Next Run value.
Happy-path	Edit/update uses an in-place PATCH and preserves a single trigger row after branch/schedule changes.
Happy-path	Single Run Now created one invocation and its conversation link opened without 404.
Happy-path	Authorized restart returned 200 with runId/previousRunId; missing/wrong/malformed auth returned 401.
Happy-path	Verified selective cleanup after branch deletion; only main trigger remained.

Commit: 216c159

View Full Run

Tell us how we did: Give Ito Feedback