Job in background

Installazione e configurazione

Prima di qualsiasi passaggio, leggere Prima di iniziare e Nozioni di base sui terminali. Queste istruzioni presuppongono che tu abbia aperto l'intero supastack monorepo in VS Code; la sua radice package.json contrassegna la radice del repository. Nei comandi pnpm, un pacchetto dell'area di lavoro è un'app o una cartella di codice condiviso; nel prodotto, uno spazio di lavoro è il contenitore dei dati di un team e il limite di sicurezza. corepack pnpm --filter ... seleziona un pacchetto dal monorepo mentre i comandi vengono eseguiti dalla sua radice. Se hai aperto solo una cartella mobile o desktop sincronizzata, non contiene il backend Web, la configurazione di Docker o gli script root: esegui il backend da questo monorepo o da un server ospitato raggiungibile e utilizza gli script della cartella della piattaforma. Una variabile di ambiente è un'impostazione denominata memorizzata in un file .env locale o nel dashboard dell'hosting; riavvia l'app pertinente dopo averla modificata e mantieni i segreti del server fuori dai valori NEXT_PUBLIC_ e EXPO_PUBLIC_.

1. Apri apps/web/src/job-handlers.ts e apps/web/src/scheduler-runtime.ts in VS Code. Un lavoro è un lavoro di base; lo scheduler decide quando accodarlo.

2. Per un tick locale, impostare lo stesso SCHEDULER_TICK_SECRET in apps/web/.env.local e repository-root .env; lo script tick legge il root .env, mentre l'endpoint Web legge le impostazioni dell'app.

3. Avvia Web con corepack pnpm --filter @supastack/web dev, quindi esegui corepack pnpm jobs:tick dalla root. Previsto: il terminale mostra un risultato POST da localhost:3000. Trigger.dev è un provider separato e necessita del proprio account e delle chiavi del server.

Imposta JOB_PROVIDER=trigger con TRIGGER_SECRET_KEY e TRIGGER_PROJECT_REF solo server per le submission di attività di produzione. Rivedi apps/web/trigger.config.ts e l'attività ai.generate in apps/web/trigger prima di configurare il progetto target.

JOB_PROVIDER=trigger
TRIGGER_PROJECT_REF=your-project-reference
# Provide TRIGGER_SECRET_KEY through the server secret store.
# Local/self-hosted scheduler tick:
# SCHEDULER_TICK_SECRET=…
# SCHEDULER_TICK_URL=http://localhost:3000

Comandi da copiare

Segui i commenti per vedere in quale cartella viene eseguito un comando. Se due terminali sono etichettati, apri due finestre di terminale e mantieni il primo comando in esecuzione mentre usi il secondo.

# Terminal 1 — start the Web app from the monorepo root:
corepack pnpm --filter @supastack/web dev

# Terminal 2 — run one scheduler tick from the monorepo root:
corepack pnpm jobs:tick

Flusso di implementazione

Il contratto JobRunner condiviso promette enqueue, status e cancel. La semantica specifica del workflow appartiene a Trigger.dev; non dedurre scheduling, retry o garanzie di durabilità dall'interfaccia generica.

L'ID di attività durevole dell'applicazione collega dispatch, esecuzione del worker, record di utilizzo e risultati. Un fallimento nell'allegare i metadati del run del provider dopo un enqueue confermato non deve causare un altro enqueue né invalidare il lavoro accettato.

Verifica e risoluzione dei problemi

Se il segno di spunta restituisce 404, verifica che il segreto esista in entrambi i file delle impostazioni e che corrisponda esattamente, quindi riavvia Web. Se il terminale dice che la connessione è stata rifiutata, avviare prima Web. Se non è stato eseguito alcun lavoro, verificare che una pianificazione sia abilitata e in scadenza; un segno di spunta non fa eseguire immediatamente una pianificazione futura.

Verifica che l'identificatore di attività deployato e il progetto corrispondano all'ambiente configurato. Separa l'accettazione dell'enqueue dal completamento del workflow e dalla consegna email. Leggi docs/production-ai-runtime.md per ripristino e diagnostica sicura prima di riprovare manualmente il lavoro.