PUBLICAR / Status lifecycle
Ciclo de vida do conteúdo
11 statuses cobrem todo o lifecycle: rascunho, estoque, agendamento, pipeline ativo, terminais e cancel. Cada transição é explícita — endpoint dedicado.
Os 11 statuses
O campo status num content é uma dimensão única que cobre desde rascunho até pós-publicação. Ele decide o que pode ser editado, o que aparece em cada tab do dashboard, e o que o snapshot público mostra.
| Status | Grupo | Descrição | /p/{token} |
|---|---|---|---|
draft | Pre-publish | Rascunho em construção. Sem dispatch. | 404 em /p/{token} (private) |
stored | Pre-publish | Pronto pra publicar, sem data marcada. | 404 em /p/{token} (private) |
awaiting_media | Pre-publish | Aguardando upload large media (>100MB) via presigned URL. | 404 em /p/{token} |
scheduled | Pre-publish | Agendado pra data futura. O QStash dispara no horário (notBefore). | Liberado (auto-bump shareable) |
queued | Pipeline | Worker pegou, dispatch pendente. | Renderiza SSR |
publishing | Pipeline | 1+ job em dispatch contra plataforma. | Renderiza SSR |
processing_remote | Pipeline | Provider aceitou, transcoding async (YT/LI). Polling automático. | Renderiza SSR |
published | Terminal | Todos os jobs concluídos com sucesso. | Renderiza SSR |
partial | Terminal | Alguns jobs OK, outros failed. Retry recupera só os failed. | Renderiza SSR (mostra só plataformas published) |
failed | Terminal | Todos os jobs falharam. Retry reprocessa tudo. | 404 |
cancelled | Cancelado | Usuário cancelou. Reativável (→ draft ou stored). | 404 |
Transições válidas
Cada transição é validada pelo domain layer (atomic-claim no DB). Tentativas inválidas retornam 422 invalid_transition. As transições internas do pipeline (queued → publishing, etc) são feitas pelo worker — você não chama elas direto.
| De | Para | Via |
|---|---|---|
draft | stored | POST /move-to-stored |
draft | scheduled | POST /schedule |
draft | queued | POST /publish |
stored | draft | POST /move-to-draft |
stored | scheduled | POST /schedule |
stored | queued | POST /publish |
scheduled | publishing | QStash dispara no horário (notBefore) |
scheduled | draft|stored | POST /move-to-draft ou /move-to-stored |
queued | publishing | worker |
publishing | processing_remote | provider sync |
publishing | published|partial|failed | worker terminal |
processing_remote | published|partial|failed | poller terminal |
partial | publishing | POST /retry (só failed jobs) |
failed | publishing | POST /retry (tudo) |
draft|stored|scheduled|awaiting_media|queued | cancelled | POST /cancel (ou DELETE) |
cancelled | draft|stored | POST /reactivate |
Fluxos típicos
Publish direto (legacy)
POST /contents (status=queued) → publishing → publishedRascunho → publish
POST /contents (status=draft) → PATCH (edita) → POST /publish → publishing → publishedEstoque + agendamento
POST /contents (status=stored) → POST /schedule → scheduled → (QStash no horário) → publishing → publishedEdit pós-publish
POST /clone (do publicado) → PATCH (edita o clone) → POST /publish (clone)O original fica intacto (snapshot público continua válido).
Retry depois de partial
published em IG + failed em FB (partial) → POST /retry → reprocessa só FBIG não é re-publicado (preservado). Pra failed total (todos falharam), retry reprocessa tudo.