For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /it/docs/modules/schedules.md (or send Accept: text/markdown).

Task schedulati

Lavoro ricorrente del workspace tramite le schedule actions.

Chiedi informazioni su questa guida

Procedura dettagliata per principianti

Prerequisiti: leggi le due guide per principianti di seguito, completa la configurazione locale del Web e apri questo monorepo alla radice nel tuo editor. Le impostazioni Web appartengono a apps/web/.env.local; Next.js non legge la radice .env. /dashboard nella modalità falsa predefinita è una demo senza database; /auth necessita di un database migrato.

Termini rapidi: uno spazio di lavoro è costituito da utenti, dati e impostazioni separati di un team. Il server è il backend affidabile; mantenere le chiavi del provider fuori dal browser e dal codice del telefono. Una migrazione è una modifica del database con versione che crea o aggiorna tabelle. Un modello AI è il motore che risponde; il catalogo dei modelli è l'elenco del server degli ID e dei prezzi dei modelli disponibili. Un fornitore è un servizio esterno come un servizio di intelligenza artificiale, posta elettronica o fatturazione. Un diritto è una concessione che consente a un'area di lavoro di utilizzare una funzionalità. Un webhook è un messaggio che un servizio invia allo URL di un altro servizio.

1. Aprire Settings → Developers e utilizzare i controlli Pianificazioni per creare un lavoro di prova con un tempo di esecuzione UTC.

2. Mantenere l'app in esecuzione e rendere disponibile all'app e al terminale lo stesso SCHEDULER_TICK_SECRET solo per server; esegui il comando seguente dalla root del repository.

3. Confermare gli anticipi di scadenza e il lavoro raggiunge il proprio stato. Se non viene eseguito nulla, controlla l'ora UTC, il provider dello scheduler e i registri del server; non incollare mai il segreto nella chat.

Per il codice personalizzato, inizia con prompts/README.md in dotazione e copia il prompt più vicino: prompts/new-app-screen.md per la schermata di un'app o prompts/new-landing-page.md per una pagina pubblica. Per il lavoro su server, database o provider, assegna al tuo agente di codifica il compito di questa guida e chiedigli di leggere AGENTS.md, .ai/PROJECT_CONTEXT.md e i mirror .ai/ corrispondenti; controllare gli esatti file sorgente nominati qui; elencare file e controlli prima della modifica; preservare la proprietà dello spazio di lavoro e i segreti solo del server; e mostrarti la differenza. Indicagli il comportamento desiderato, i campi di input e output, i ruoli consentiti, i successi e gli errori previsti e l'account, il fornitore o il dispositivo di prova. Utilizzare valori campione; non incollare mai un vero segreto.

corepack pnpm jobs:tick

Archiviare il lavoro ricorrente nel database

La pianificazione delle impostazioni memorizza il tipo di lavoro e la regola cron nelle righe job_schedule con ambito area di lavoro. I campi Cron vengono valutati in UTC. createDrizzleJobScheduler.claimDueSchedules richiede le righe dovute utilizzando FOR UPDATE SKIP LOCKED, avanza all'esecuzione successiva, quindi invia i gestori.

Il generico JobRunner promette accodamento/stato/annullamento. La ricorrenza appartiene alle righe dello scheduler; La semantica del flusso di lavoro Trigger.dev rimane esplicita.

Ticchettii dello scheduler dell'unità

Impostare uno SCHEDULER_TICK_SECRET solo server per abilitare POST /api/internal/scheduler-tick. corepack pnpm jobs:tick lo chiama per dev/CI; la configurazione assente restituisce 404. Sotto JOB_PROVIDER=trigger, il cron scheduler.tick distribuito guida lo scheduler.

# Against a running local app, with SCHEDULER_TICK_SECRET configured:
corepack pnpm jobs:tick

Verificare separatamente i reclami e l'esecuzione

Testa i segni di spunta sovrapposti, le regole di scadenza/non scadenza, le righe disabilitate, gli errori del gestore, l'annullamento e la pianificazione di un'altra area di lavoro. Ispezionare separatamente il reclamo/anticipo e il completamento del lavoro; una riga rivendicata non è la prova del lavoro completato.

Installazione e configurazione

Il lavoro schedulato — digest, pulizie, rinnovi — passa per schedule-actions invece di timer ad hoc: listWorkspaceSchedules, upsertScheduleAction e removeScheduleAction gestiscono i task cron di un workspace.

Uno schedule nomina il task, l'espressione cron e il workspace sotto cui gira. Il worker risolve il contesto al momento dell'esecuzione, quindi uno schedule in pausa o eliminato smette di produrre lavoro senza redeploy.

listWorkspaceSchedules()
upsertScheduleAction({ task, cron })
removeScheduleAction(formData)

Flusso di implementazione

Tratta ogni esecuzione schedulata come input non fidato: risolvi di nuovo workspace ed entitlement dentro la run, perché lo stato può essere cambiato dalla registrazione. Rendi il task idempotente — una run ritentata o sparata due volte non deve duplicare gli effetti.

Gli schedule sono superficie operativa: tienili visibili in settings o log così uno schedule bloccato o in fuga viene trovato prima che gli utenti se ne accorgano.

Verifica e risoluzione dei problemi

Spara lo schedule manualmente in una sandbox, mettilo in pausa, verifica che un workspace disabilitato smetta di produrre run e conferma che un firing duplicato produca un solo effetto. Tieni le espressioni cron in configurazione gestita, non sparse nel codice dei task.