Configurar jobs em segundo plano

Instalação e configuração

Antes de qualquer etapa, leia Antes de começar e Noções básicas sobre terminal. Estas instruções presumem que você abriu o monorepo supastack completo no VS Code; sua raiz package.json marca a raiz do repositório. Nos comandos pnpm, um pacote de espaço de trabalho é um aplicativo ou uma pasta de código compartilhado; no produto, um espaço de trabalho é o contêiner de dados e o limite de segurança de uma equipe. corepack pnpm --filter ... seleciona um pacote do monorepo enquanto os comandos são executados a partir de sua raiz. Se você abriu apenas uma pasta móvel ou desktop sincronizada, ela não contém o back-end da Web, a configuração do Docker ou os scripts raiz: execute o back-end deste monorepo ou de um servidor hospedado acessível e use os próprios scripts da pasta da plataforma. Uma variável de ambiente é uma configuração nomeada armazenada em um arquivo .env local ou no painel de hospedagem; reinicie o aplicativo relevante após alterá-lo e mantenha os segredos do servidor fora dos valores NEXT_PUBLIC_ e EXPO_PUBLIC_.

1. Abra apps/web/src/job-handlers.ts e apps/web/src/scheduler-runtime.ts no VS Code. Um trabalho é um trabalho em segundo plano; o agendador decide quando enfileirá-lo.

2. Para um tick local, defina o mesmo SCHEDULER_TICK_SECRET em apps/web/.env.local e o repositório-root .env; o script tick lê o .env raiz, enquanto o endpoint da Web lê as configurações do aplicativo.

3. Inicie a Web com corepack pnpm --filter @supastack/web dev e execute corepack pnpm jobs:tick da raiz. Esperado: o terminal mostra um resultado POST de localhost:3000. Trigger.dev é um provedor separado e precisa de sua própria conta e chaves de servidor.

Define JOB_PROVIDER=trigger com TRIGGER_SECRET_KEY e TRIGGER_PROJECT_REF só de servidor para submissões de tarefas de produção. Reveja apps/web/trigger.config.ts e a tarefa ai.generate em apps/web/trigger antes de configurar o projeto alvo.

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

Comandos para copiar

Siga os comentários para ver em qual pasta um comando é executado. Se dois terminais estiverem rotulados, abra duas janelas de terminal e mantenha o primeiro comando em execução enquanto usa o segundo.

# 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

Fluxo de implementação

O contrato JobRunner partilhado promete enqueue, status e cancel. A semântica específica de workflow pertence ao Trigger.dev; não deduzas agendamento, retries ou garantias de durabilidade da interface genérica.

O ID de tarefa durável da aplicação liga dispatch, execução do worker, registos de utilização e resultados. Uma falha ao anexar metadados do run do fornecedor após um enqueue confirmado não deve causar outro enqueue nem invalidar o trabalho aceite.

Verificação e resolução de problemas

Se a marca retornar 404, confirme se o segredo existe em ambos os arquivos de configurações e se corresponde exatamente e reinicie o Web. Se o terminal disser que a conexão foi recusada, inicie o Web primeiro. Se nenhum trabalho foi executado, verifique se um agendamento está habilitado e vencido; um tick não faz com que um agendamento futuro seja executado imediatamente.

Verifica que o identificador de tarefa deployed e o projeto correspondem ao ambiente configurado. Separa a aceitação do enqueue da conclusão do workflow e da entrega de email. Lê docs/production-ai-runtime.md para recuperação e diagnósticos seguros antes de tentar trabalho manualmente.