Todo erro sai no stderr como {"error":{"code","source","stage","cause","recovery"}} (ou em texto, num terminal). O code é estável e pode ser usado em scripts; o cause nunca contém segredo. Todo campo de texto do erro (e dos avisos warning [...]) passa pela mesma redação da saída: o valor de parâmetros de token, como o de uma URL assinada de foto citada na causa, vira …; em texto, o que tem caractere de controle ou bidi sai entre aspas. source e stage são omitidos quando não se aplicam.
| Exit | Significado |
|---|---|
| 0 | OK |
| 1 | erro inesperado |
| 2 | uso inválido |
| 3 | autenticação |
| 4 | conflito de version |
| 5 | não encontrado |
| 6 | permissão negada |
| 7 | rede ou servidor |
Um exit code agrupa vários code. Automação deve decidir pelo code, nunca só pelo exit: o exit 4 vale tanto para version_conflict (nada foi gravado, ou a gravação foi recusada; reler e repetir é seguro) quanto para assignees_postcondition_failed e field_values_postcondition_failed (a gravação foi aplicada; repetir às cegas não é seguro) e para project_changed (parte do plano pode ter sido aplicada; o resultado no stdout diz o quê), status_order_postcondition_failed (a ordem foi gravada), attachment_postcondition_failed (o anexo foi gravado) e epic_links_postcondition_failed (o vínculo novo pode ter sido gravado: cause diz). No exit 1, write_applied e todo *_unconfirmed (story_create_unconfirmed, story_update_unconfirmed, task_create_unconfirmed, task_update_unconfirmed, comment_unconfirmed, attachment_unconfirmed, field_create_unconfirmed, status_create_unconfirmed, status_order_unconfirmed) e project_apply_interrupted também são "gravado, ou talvez gravado: não repetir às cegas"; epic_link_unconfirmed e epic_replace_incomplete são a exceção: o vínculo é idempotente e rodar o mesmo comando de novo converge; story_created_link_failed diz que a story foi criada e que repetir a criação a duplicaria, e story_updated_link_failed que os campos foram gravados e que repetir o update os repetiria.
Escrita enviada sem resposta conclusiva — rede depois de aberta a conexão, timeout, 5xx ou redirect 3xx (a CLI nunca segue Location; um proxy pode ter repassado o pedido) — nunca sai com exit 7 num comando curado (US #274): a alteração é conferida por releitura (*_update_unconfirmed quando não se confirma) e a criação sai sempre com *_create_unconfirmed, comment_unconfirmed ou attachment_unconfirmed, nomeando as candidatas (decisão de 2026-10-03, opção B). Um PATCH recusado por conflito de version cuja releitura para a nova tentativa falha sai com o erro dessa leitura: nada foi gravado. O corpo de um 3xx nunca é copiado na cause (ele diz para onde o redirect aponta). Exit 7 fica para leitura pura, para conexão que nem abriu (DNS, conexão recusada: nada chegou ao Taiga), para o login (auth) e para o taiga api, que não tem como conferir.
| code | exit | source | quando ocorre | recuperação |
|---|---|---|---|---|
usage |
2 | — | flag, argumento ou combinação inválida; comando desconhecido | taiga --help |
delete_not_confirmed |
2 | — | taiga api DELETE sem --confirm-delete; ou a troca de épico (epic link --replace, story update --replace-epic) sem --confirm-delete, também com --dry-run; nada é enviado |
repetir com --confirm-delete; para só acrescentar o épico, sem apagar os outros vínculos, usar epic link sem --replace ou --epic |
invalid_request |
2 | api |
a API respondeu 4xx que não é 401, 403, 404 nem conflito de version |
corrigir o corpo ou a query |
config_no_home |
2 | env |
HOME e XDG_* ausentes ou relativos |
definir TAIGA_CONFIG e TAIGA_STATE_DIR |
config_unreadable |
2 | config ou file |
a config ou o .taiga.toml não pôde ser lido |
conferir permissões |
config_invalid |
2 | config ou file |
TOML inválido na config ou no .taiga.toml |
corrigir a sintaxe |
config_no_url |
2 | config |
nenhuma URL em flag, env, .taiga.toml ou config |
taiga auth login --url …, TAIGA_URL ou .taiga.toml |
config_invalid_url |
2 | config |
URL sem HTTPS (fora de localhost), com userinfo, query ou fragmento | usar https://host |
auth_no_source |
3 | config ou env |
sem TAIGA_TOKEN, sem sessão e sem fonte de segredo |
taiga auth login ou TAIGA_TOKEN |
auth_untrusted_url |
3 | env ou file |
TAIGA_TOKEN/TAIGA_PASSWORD/TAIGA_PASSWORD_FILE definidos, ou taiga auth login sem --url, e a URL veio só do .taiga.toml, sem host correspondente na config; nada é enviado |
TAIGA_URL/--url com essa URL, ou taiga auth login --url … |
auth_invalid_credentials |
3 | api |
POST /auth respondeu 400 ou 401 |
conferir usuário e fonte de segredo |
auth_rejected |
3 | api |
a API respondeu 401 a uma chamada autenticada | taiga auth status --diagnose |
session_expired |
3 | session_cache |
refresh recusado, ou sessão vencida com o cache somente leitura (sandbox) | taiga auth refresh fora do sandbox, ou taiga auth login |
session_cache_readonly |
3 | session_cache |
taiga auth refresh com o state dir somente leitura; ou nenhuma sessão, cache somente leitura e sem TAIGA_PASSWORD/TAIGA_PASSWORD_FILE (keyring, secret_command e arquivo não são usados no sandbox). Como aviso (stderr, sem falhar): token obtido por login com senha do env mantido só em memória |
rodar fora do sandbox; ou incluir o state dir em writable_roots |
session_cache_write_failed |
— | — | aviso: a sessão nova não pôde ser gravada por outro motivo | conferir o state dir |
password_file_unreadable |
3 | env |
TAIGA_PASSWORD_FILE não pôde ser lido |
conferir caminho e permissões |
password_file_empty |
3 | env |
TAIGA_PASSWORD_FILE vazio |
preencher o arquivo |
secret_command_timeout |
3 | secret_command |
o comando não respondeu em 10 s (por exemplo gpg esperando o pinentry) | se o stderr citar gpg/pinentry: rodar o comando uma vez com export GPG_TTY=$(tty) num terminal fora do sandbox |
secret_command_not_found |
3 | secret_command |
executável inexistente ou secret_command vazio |
corrigir o caminho (sem shell) |
secret_command_failed |
3 | secret_command |
exit diferente de 0; cause = exit status N; seguido só dos padrões conhecidos do stderr (gpg, pinentry, inappropriate ioctl, no tty). O texto do stderr e o argv nunca são copiados, porque podem conter o segredo |
rodar o comando à mão; dica de GPG_TTY se for gpg |
secret_command_empty |
3 | secret_command |
o comando não imprimiu nada | conferir o comando |
file_secret_missing |
3 | file |
arquivo do --insecure-storage ausente ou ilegível |
taiga auth login --insecure-storage de novo |
file_secret_insecure_permissions |
3 | file |
arquivo do segredo legível por grupo ou outros | chmod 600 |
keyring_unavailable |
3 | keyring |
não foi possível falar com o Secret Service | seção "Headless Linux keyring" do README, ou --secret-command |
keyring_service_unavailable |
3 | keyring |
nenhum org.freedesktop.secrets no session bus (ou a ativação falhou) |
idem |
keyring_timeout |
3 | keyring |
o Secret Service não respondeu em 5 s | idem |
keyring_access_denied |
3 | keyring |
o Secret Service recusou o acesso | idem |
keyring_locked |
3 | keyring |
coleção bloqueada | gnome-keyring-daemon --unlock (README) |
keyring_prompt_required |
3 | keyring |
o cofre pediu interação; a CLI nunca abre prompt | desbloquear antes, ou --secret-command |
keyring_no_default |
3 | keyring |
Secret Service sem coleção padrão (daemon iniciado antes do unlock) | pkill -x gnome-keyring-d e desbloquear de novo (README) |
keyring_unsupported |
3 | keyring |
keyring fora do Linux | --secret-command |
secret_missing |
3 | keyring |
nenhuma credencial guardada para esta URL e usuário | taiga auth login |
secret_ambiguous |
3 | keyring |
mais de uma credencial para a mesma referência | apagar as duplicadas com secret-tool clear service taiga-cli |
payload_too_large |
2 | api |
o proxy na frente do Taiga respondeu 413 (corpo grande demais; no attachment upload, arquivo acima do limite do proxy: 50 MB na Basis). A CLI não impõe limite próprio; cause traz a página do proxy. Nada foi gravado |
enviar um arquivo menor |
field_definition_conflict |
2 | — | field create com um nome que já existe no projeto com outro tipo, ou com outra descrição quando --description foi informado; nada é enviado |
rever a definição existente (a CLI não altera definições) |
ambiguous_name |
2 | — | nome de status, milestone, swimlane, usuário ou campo customizado repetido no projeto; story close/task close sem --status num projeto com mais de um status fechado; em project plan/apply, dois status ou dois campos com o mesmo nome no Taiga |
usar o id, ou escolher com --status; em project, renomear a duplicata no Taiga |
definition_drift |
2 | — | project apply: um status ou campo declarado já existe com outra cor, outro closed, outro tipo ou outra descrição, ou com o nome diferente só em maiúsculas; nada é enviado. O plan lista cada caso em drift |
corrigir o arquivo ou o projeto (a CLI nunca altera definições existentes) |
unsupported_operation |
2 | — | a flag depende de um contrato do Taiga que a CLI não cumpre com segurança; nada é enviado. Hoje nenhum comando curado a usa (o --epic de story create/update passou a ser suportado no PR 253-2) |
usar taiga api |
version_conflict |
4 | api |
PATCH/PUT com version desatualizado ou ausente (400 com chave version, 409 ou 412); com --auto-version, conflito em campo alterado por outra pessoa; em story update com responsáveis, assigned_to/assigned_users mudaram entre a leitura e a releitura antes do PATCH (nada é enviado); em story field set, version recusado pelo servidor (maior que o atual); no vínculo de épico, os épicos da story mudaram entre a leitura e a releitura antes do POST (nada é enviado) |
reler e repetir; --auto-version ou --force-version |
assignees_postcondition_failed |
4 | api |
story update que mexe em responsáveis: o PATCH foi aplicado, mas a releitura não bate com o pedido (quem devia entrar não está, quem devia sair continua, o responsável principal não é o pedido, alguém sumiu sem ser removido) ou a version pulou (outra escrita caiu junto do PATCH): vale a version da resposta do PATCH ou, se ela não decodificar, a da releitura depois da escrita, que precisa ser exatamente a seguinte à da releitura anterior; a checagem nunca é pulada. O Taiga não detecta troca concorrente de assigned_to (ver docs/api-notes.md); cause traz o estado encontrado. Nunca há repetição automática |
não repetir às cegas: conferir com taiga story get e corrigir o que for preciso |
field_values_postcondition_failed |
4 | api |
story field set/task field set (com ou sem --unset): o PATCH foi aplicado, mas a resposta não é a version seguinte à da leitura que calculou o merge, ou não traz exatamente o dicionário enviado (se a resposta não decodificar, vale a releitura). Significa que outra escrita caiu junto: o Taiga aceita version antigo nesse recurso e não acusa conflito (ver docs/api-notes.md). cause traz os valores encontrados. Nunca há repetição automática; --force-version pula a checagem |
não repetir às cegas: conferir com taiga story field list REF (ou taiga task field list REF) e gravar o que faltar |
epic_links_postcondition_failed |
4 | api |
vínculo de épico: a escrita foi feita, mas a releitura não mostra o resultado pedido (o épico não está entre os da story; na troca, sobrou outro épico), ou, na troca, um épico que não estava na primeira leitura apareceu, ou o épico novo sumiu, entre o POST e os DELETE (nada foi apagado). cause diz se o vínculo novo está gravado ("is saved") ou não ("is not among them"). O vínculo não tem version e o Taiga não acusa a corrida; cause traz os épicos encontrados |
não repetir às cegas: conferir com taiga story get e decidir |
attachment_postcondition_failed |
4 | api |
attachment upload: o anexo foi gravado, mas a resposta mostra sha1, size ou objeto diferentes do arquivo enviado (por exemplo, o arquivo mudou entre o cálculo do hash e o envio); cause traz o id e os valores dos dois lados |
não repetir às cegas: conferir com taiga attachment list e decidir |
project_changed |
4 | — | project apply: o projeto mudou durante a execução — um status ou campo com o mesmo nome apareceu com outros valores, ou um com nome igual a menos de maiúsculas apareceu, entre o plano e a criação (o catálogo é relido antes de cada criação), ou a releitura final ainda encontra ações ou drift (inclusive dois nomes iguais a menos de maiúsculas); na reordenação, a ordem relida logo antes do bulk_update_order não é a do plano (nada é enviado). O que já foi aplicado está em applied; nada é desfeito nem repetido |
rodar taiga project plan de novo e revisar antes de aplicar |
status_order_postcondition_failed |
4 | api |
project apply com reordenação: o bulk_update_order foi aplicado (ou teve resultado incerto: rede, 5xx ou redirect 3xx), mas a releitura logo depois não mostra a ordem pretendida — outra mudança caiu junto. O Taiga não tem controle de concorrência na ordem dos status (ver docs/api-notes.md); a conferência detecta, não impede. cause traz a ordem encontrada e a pretendida. Nunca há repetição automática |
não repetir às cegas: conferir com taiga status list, rodar taiga project plan e decidir |
write_applied |
1 | a da releitura (api ou network) |
a escrita (POST/PATCH/PUT) foi confirmada pelo status HTTP, mas nem a resposta dela decodificou (ou chegou inteira: conexão caída no meio do corpo depois do 2xx) nem a releitura funcionou; cause traz o status da escrita e a falha da releitura. Em taiga api e na criação (story create, task create, field create), que não têm como reler sem a resposta, o corpo truncado depois do 2xx já dá write_applied. No status do project apply, o corpo perdido depois do 201 é conferido no catálogo: se a leitura falha (rede, 5xx, 3xx), sai write_applied, e não o erro repetível da leitura, mesmo sendo a primeira ação do plano (a recuperação cita taiga project plan). O cliente nunca repete essa escrita. Sai com 1, e não com 7, para que scripts que repetem erros de rede não repitam a escrita |
não repetir o comando: a alteração já está gravada; conferir com taiga story get ou taiga story list (numa task, a recuperação cita taiga task get REF ou, na criação, taiga task list --story REF) |
comment_unconfirmed |
1 | a do PATCH (api ou network) |
story comment/task comment: o PATCH não teve resposta conclusiva (rede depois de aberta a conexão, timeout, 5xx ou redirect 3xx). É sempre este erro, nunca sucesso, mesmo que o comentário esteja no histórico (opção B, estendida ao comentário na US #274): outro processo com a mesma conta pode ter publicado o mesmo texto. A cause lista os ids das entradas novas desta conta com exatamente o texto enviado, ou diz que nenhuma foi encontrada, ou que o histórico não pôde ser lido; ausência não prova nada, porque um gateway pode responder 5xx enquanto o PATCH ainda roda no servidor e grava depois da conferência. O comentário pode ter sido publicado. Nunca há repetição automática. Sai com 1, e não com 7, para que scripts que repetem erros de rede não publiquem duas vezes; network_error (exit 7) só sai quando a conexão nem abriu (DNS, conexão recusada), ou seja, nada chegou ao Taiga |
não repetir às cegas (publicaria de novo, e um comentário ainda não encontrado pode gravar depois): esperar e conferir com taiga story comments REF (ou taiga task comments REF) |
story_create_unconfirmed |
1 | a do POST (api ou network) |
story create (com ou sem --epic): o POST userstories não teve resposta conclusiva (rede depois de aberta a conexão, timeout, 5xx ou redirect 3xx). É sempre este erro, nunca sucesso, pelo mesmo motivo do task_create_unconfirmed. A cause lista ref e id das candidatas (stories novas do projeto desde a leitura anterior ao POST, desta conta, com o mesmo subject), ou diz que nenhuma foi encontrada, ou que a lista não pôde ser lida. A story pode ter sido criada; o vínculo do --epic não é tentado. Nunca há repetição automática; sai com 1, e não com 7, porque repetir criaria outra story |
não repetir o comando às cegas (criaria outra story, e uma ainda não encontrada pode ser gravada depois): inspecionar as candidatas com taiga story get REF e o projeto com taiga story list; com --epic, vincular a escolhida com taiga epic link EPIC REF |
task_create_unconfirmed |
1 | a do POST (api ou network) |
task create: o POST tasks não teve resposta conclusiva (rede depois de aberta a conexão, timeout, 5xx ou redirect 3xx). É sempre este erro, nunca sucesso, mesmo que a task esteja lá (decisão de 2026-10-03): nenhuma comparação de estado prova que uma task veio deste POST, porque outro processo com a mesma conta pode ter criado a mesma task e campos como valores customizados e watchers não entram na comparação. A cause lista ref e id das candidatas (tasks novas desde a leitura anterior ao POST, na mesma story, desta conta, com o mesmo subject), ou diz que nenhuma foi encontrada, ou que a lista não pôde ser lida; lista vazia ou ilegível não prova que a task não existe, porque o pedido pode gravar depois. A task pode ter sido criada. Nunca há repetição automática; sai com 1, e não com 7, porque repetir criaria outra task |
não repetir o comando às cegas (criaria outra task, e uma task ainda não encontrada pode ser gravada depois): inspecionar as candidatas com taiga task get REF e a story com taiga task list --story REF |
story_update_unconfirmed, task_update_unconfirmed |
1 | a do PATCH (api ou network) |
story update/story close/story field set (inclusive bloqueio, swimlane e responsáveis) e task update/task close/task field set: o PATCH não teve resposta conclusiva (rede depois de aberta a conexão, timeout, 5xx ou redirect 3xx) e a releitura da story ou da task (ou dos valores, no field set) não mostra todos os campos enviados com o valor pedido, ou não pôde ser feita; no field set, também quando os valores batem mas a version não é a seguinte à da leitura (outra escrita caiu junto e pode ter sido sobrescrita: esse recurso não tem OCC); na story com responsáveis, também quando a releitura não passa nas conferências do assignees_postcondition_failed (quem devia entrar, sair, o responsável principal, a version seguinte à da releitura antes do PATCH); com --force-version, essa conferência de versão é pulada, como no caminho normal, e só os valores são comparados. A alteração pode ter sido aplicada. Quando a releitura mostra os campos, o comando termina com sucesso. Sai com 1, e não com 7: repetir aplicaria de novo um --append-description |
não repetir o comando às cegas: esperar, conferir com taiga story get REF/taiga task get REF (ou field list REF) e repetir só o que ainda faltar |
attachment_unconfirmed |
1 | a do POST (api ou network) |
attachment upload: o POST não teve resposta conclusiva (rede depois de aberta a conexão, timeout, 5xx ou redirect 3xx). É sempre este erro, nunca sucesso (opção B, estendida ao anexo na US #274): a cause lista os ids novos com o mesmo nome e sha1 (outro processo com a mesma conta pode tê-los enviado), ou diz que a lista não os mostra, ou que não pôde ser lida. O anexo pode ter sido gravado (o servidor pode terminar depois da conferência). Nunca há repetição automática; sai com 1, e não com 7, pelo mesmo motivo do comment_unconfirmed. Corpo perdido depois de um 2xx não é este caso: a gravação está confirmada e o anexo novo é a resposta; network_error (exit 7) só quando a conexão nem abriu |
não enviar de novo às cegas (anexaria duas vezes): esperar e conferir com taiga attachment list REF |
field_create_unconfirmed |
1 | a do POST (api ou network) |
field create (e o campo de um project apply): o POST da definição não teve resposta conclusiva (rede depois de aberta a conexão, timeout, 5xx — inclusive o 500 de dois POST simultâneos, ver docs/api-notes.md — ou redirect 3xx). É sempre este erro (opção B): a cause nomeia a definição com o mesmo nome encontrada depois (id e tipo), ou diz que nenhuma foi encontrada, ou que o catálogo não pôde ser lido |
não supor que falta: esperar e conferir com taiga field list --kind KIND. O Taiga recusa segunda definição com o mesmo nome, então rodar de novo nunca a duplica (e devolve a existente se for compatível) |
status_create_unconfirmed |
1 | a do POST (api ou network) |
project apply: o POST userstory-statuses não teve resposta conclusiva (rede depois de aberta a conexão, timeout, 5xx ou redirect 3xx). É sempre este erro (opção B): a cause nomeia o status com o mesmo nome encontrado depois (id, cor, closed), ou diz que nenhum foi encontrado, ou que o catálogo não pôde ser lido. O que já foi aplicado está em applied |
rodar taiga project plan para ver o que falta; o Taiga recusa segundo status com o mesmo nome, então um novo apply nunca o duplica |
status_order_unconfirmed |
1 | a do POST (api ou network) |
project apply com reordenação: o bulk_update_order não teve resposta conclusiva (rede depois de aberta a conexão, 5xx ou redirect 3xx) e a releitura dos status, que decidiria, falhou |
não repetir às cegas: conferir taiga status list, rodar taiga project plan e decidir |
project_apply_interrupted |
1 | a do erro original | project apply: uma ou mais ações foram aplicadas (estão em applied) e depois uma falha que sozinha seria exit 7 (por exemplo a leitura do catálogo para a próxima ação ou a releitura final, com rede ou 5xx) interrompeu o resto. cause traz o código original entre colchetes |
não supor que nada foi gravado: rodar taiga project plan para ver o que falta e aplicar de novo (o apply replaneja e nunca cria um nome duas vezes) |
epic_link_unconfirmed |
1 | a do POST (api ou network) |
epic link, --epic ou --replace-epic: o POST epics/<id>/related_userstories não teve resposta conclusiva (rede depois de aberta a conexão, timeout, 5xx, redirect 3xx — a CLI não segue e um proxy pode ter repassado o pedido —, resposta ilegível) e a releitura da story não mostra o épico, ou não pôde ser lida. O vínculo pode ter sido criado; nenhum vínculo antigo foi apagado. Nunca há repetição automática. Quando a releitura mostra o vínculo, o comando segue; network_error (exit 7) só quando a conexão nem abriu |
rodar o mesmo comando de novo: o Taiga recusa vínculo duplicado (400), que a CLI confere pela releitura |
epic_replace_incomplete |
1 | api |
troca de épico (--replace/--replace-epic): o vínculo novo foi gravado, mas um DELETE de vínculo antigo falhou (rede, 5xx, 403) ou a story não pôde ser relida antes de apagar. cause traz o estado: linked, removed e remaining (o primeiro de remaining pode ter sido apagado se a resposta se perdeu). Cada DELETE é enviado uma vez só |
rodar o mesmo comando de novo: ele relê a story e termina a troca (DELETE repetido que dá 404 conta como feito). Quando o Taiga recusou o DELETE (4xx, como 403 sem modify_epic), repetir não adianta e o recovery diz isso: conferir a permissão com taiga auth status --diagnose ou remover o vínculo restante pela interface web |
story_updated_link_failed |
1 | a do erro do vínculo | story update com outros campos e --epic/--replace-epic: o PATCH dos campos foi gravado, mas o vínculo falhou depois (qualquer erro: rede, forbidden, conflito nos épicos, resultado incerto, troca incompleta). cause traz o código original do vínculo entre colchetes ([version_conflict], [epic_link_unconfirmed], [network_error]…) e o estado. Nunca sai com 7 nem com o código original, que poderia ser lido como "seguro repetir" |
não repetir o update (repetiria as outras mudanças, como --append-description). O recovery compõe esse aviso com a orientação do erro do vínculo: resultado incerto ou troca interrompida → taiga epic link EPIC REF (com --replace --confirm-delete na troca), que converge; épicos mudados por outra pessoa (version_conflict, epic_links_postcondition_failed) → conferir com taiga story get REF e decidir antes de nova troca; DELETE recusado ou forbidden → conferir modify_epic (taiga auth status --diagnose) e só então concluir |
story_created_link_failed |
1 | a do erro do vínculo | story create --epic: a story foi criada, mas o vínculo com o épico falhou (qualquer erro, inclusive forbidden e rede). cause traz a ref da story criada e o erro do vínculo |
não repetir o create (criaria outra story). O recovery mantém a orientação do erro do vínculo: resultado incerto → taiga epic link EPIC REF com a ref criada; épicos mudados por outra pessoa → conferir com taiga story get REF antes; permissão → a recuperação dela e depois o epic link |
attachment_url_untrusted |
1 | api |
attachment download: o url assinado devolvido pelo Taiga não é da mesma origem (esquema, host e porta) da URL em uso; a CLI não segue o token para outro lugar e não faz requisição |
não repetir: conferir o MEDIA_URL da instância (TAIGA_SITES_DOMAIN) e a --url em uso |
not_found |
5 | api ou — |
a API respondeu 404; ou nome, ref de épico ou usuário inexistente no projeto (usuário fora de memberships também); ou epic list/epic get/epic link (e --epic/--replace-epic em story) num projeto com o módulo de épicos desligado ("the epics module is disabled in this project") |
conferir o caminho, a ref ou o nome; para épicos, ligar o módulo nas configurações do projeto ou ler por taiga api |
forbidden |
6 | api |
a API respondeu 403; ou project apply (também com --dry-run) sem admin_project_values no projeto, conferido antes de qualquer escrita |
a conta não tem permissão; em project apply, usar a conta de um admin do projeto |
network_error |
7 | network |
falha de rede, DNS, TLS ou timeout de 30 s (em attachment upload/download, o --timeout da transferência), numa leitura, ou numa escrita cuja conexão nem abriu (DNS, conexão recusada: nada foi enviado). Escrita curada enviada sem resposta segue para releitura (*_unconfirmed, exit 1) ou, com status 2xx, write_applied; só taiga api e o login ainda dão 7 depois de enviar |
conferir a conectividade (agentes em sandbox precisam de rede) |
local_write_failed |
1 | file |
attachment download: o sistema de arquivos local falhou (criar o temporário, gravar, fechar, ajustar a permissão ou dar o nome final: disco cheio, diretório sem escrita) ou o leitor do stdout fechou. Nenhum arquivo é salvo e o download não é repetido; não é erro de rede. Com --to -, parte do arquivo pode já ter saído no stdout |
liberar espaço ou conferir permissões do destino e baixar de novo; com --to -, descartar o que foi lido |
attachment_download_mismatch |
7 | network |
attachment download: os bytes recebidos não batem com o size e o sha1 do anexo. Com arquivo, o temporário é apagado e nada é salvo; com --to -, o que já saiu no stdout deve ser descartado. É leitura: repetir é seguro |
baixar de novo |
server_error |
7 | api |
5xx numa leitura, no taiga api ou no login/refresh (resposta inesperada); numa escrita curada, o 5xx é resultado incerto (*_unconfirmed, exit 1, ou releitura) |
tentar de novo mais tarde |
unexpected_redirect |
7 | api |
a API respondeu 3xx a uma leitura, ao taiga api ou ao login; a CLI nunca segue redirects. Numa escrita curada, o 3xx é resultado incerto (*_unconfirmed, exit 1, ou releitura; US #274) |
usar a URL canônica https:// |
unexpected |
1 | — | erro não previsto | abrir issue com o comando e o stderr |