Erros de publicação agora dizem o que aconteceu, com palavras simples

Quando uma publicação falha no Mythex, a caixa de diálogo agora diz em uma frase simples o que aconteceu (o build falhou, seu app parou logo depois de iniciar, seu app não iniciou, um arquivo é grande demais ou algo deu errado do nosso lado) e oferece Corrigir com IA e Tentar de novo. A saída bruta do build e do seu app ainda chega ao agente, para que o Corrigir com IA possa lê-la e corrigir o projeto, mas você não precisa mais lê-la sozinho.

O que mudou

Uma frase que você pode usar

Toda publicação com falha agora tem um tipo, definido no momento em que a falha acontece, com base em fatos que já temos ali: qual etapa falhou, se a máquina do app registrou travamentos, se ele chegou a aceitar conexões. Não é deduzido depois, lendo o texto do erro. Cada tipo tem sua própria mensagem:

O que você vê	O que significa
“A compilação falhou.”	O comando de build ou o Dockerfile do seu projeto não compilou.
“Seu app parou logo depois de iniciar.”	Ele foi publicado, depois encerrou ou ficou reiniciando.
“Seu app não iniciou depois da publicação.”	Foi publicado, mas nunca começou a aceitar conexões.
“Este arquivo é grande demais” / arquivos demais	Um site estático ultrapassa o limite de tamanho por arquivo ou de quantidade de arquivos. A mensagem lista os arquivos.
“Este nome de link não pode ser usado para publicação.”	Mude o nome do link e publique de novo; o seu código está bem.
“A publicação está ocupada no momento”	Nada está errado com o seu app. Publique de novo em alguns minutos.
“…um problema do nosso lado, não no seu app.”	É nosso para resolver. Publique de novo em alguns minutos.

Corrigir com IA em toda falha

Toda falha mostra Corrigir com IA e Tentar de novo. Quando você usa Corrigir com IA, o agente recebe o tipo da falha e a saída completa do build ou do app, de forma privada, no próprio contexto. Se algo no seu app estiver errado, ele corrige. Se nada estiver (um momento de ocupação ou um problema do nosso lado), ele pode simplesmente publicar de novo. Você não precisa descobrir qual tipo de falha foi.

Problemas depois de ir ao ar

Uma publicação pode dar certo e o app falhar alguns minutos depois. O Mythex verifica os apps publicados com regularidade. Se um app ativo continua travando, ou continua rodando mas para de aceitar conexões, a publicação é marcada como falha, você recebe um e-mail, e o projeto mostra a mensagem com Corrigir com IA. O que o app imprimiu fica salvo para o agente ler.

Limites de tamanho verificados antes do envio

Para sites estáticos, o tamanho de cada arquivo e a quantidade total de arquivos são verificados antes de qualquer envio. Se algo estiver acima do limite, você recebe uma única mensagem listando cada arquivo grande demais, em vez de uma falha no meio do caminho.

Por que criamos isso

Antes, uma publicação com falha mostrava o que as ferramentas da publicação tinham impresso. Em uma semana no fim de setembro, a maioria das falhas mostrava textos do construtor que eram da nossa responsabilidade, e não de quem usava: contatos de cobrança, números de versão internos, caminhos de registro, erros de armazenamento. O Corrigir com IA então colava esse mesmo texto no chat. As pessoas estavam sendo pedidas para depurar a nossa infraestrutura.

Parte disso também simplesmente estava errada. Um app que nunca escutou na sua porta era apontado como “um problema do nosso lado”, quando a correção estava no próprio app. Um arquivo estático acima do limite de tamanho era apontado da mesma forma, e publicar de novo nunca poderia funcionar.

E toda parte do Mythex que reagia a uma falha (a caixa de diálogo, as notificações, o Corrigir com IA, nossos próprios alertas) costumava descobrir o que tinha acontecido procurando palavras no texto do erro. Isso quebrava sempre que a redação mudava. Agora o tipo é registrado onde a falha acontece, e todo o resto lê esse tipo.

Aplicamos a mesma regra a outros erros enquanto estávamos nisso:

Chat. Se a conexão cair durante o streaming de uma resposta, você vê a nossa frase, em vez do “Load failed” ou “Failed to fetch” do navegador.
Domínios personalizados. As mensagens sobre comprar ou conectar um domínio agora são escolhidas pelo status e pelos códigos da resposta, em vez de repassar as frases do provedor de domínios.
Geração de imagens. O cartão mostra a nossa mensagem; o agente recebe o detalhe do serviço.

Como usar

Publique normalmente pelo botão Publicar.
Se falhar, leia a mensagem de uma linha na caixa de diálogo.
Clique em Corrigir com IA. O agente lê a saída do build ou os logs do app, corrige o que estiver errado e republica se nada no app precisar de conserto.
Ou clique em Tentar de novo para publicar a mesma versão outra vez. Essa é a escolha certa para “ocupada no momento” e “um problema do nosso lado”.
Se a mensagem for sobre o nome do link, altere o nome antes de publicar de novo. Para qualquer outro erro, mantenha o mesmo nome.

Limites

Algumas falhas mostram botões diferentes: um nome de link já em uso sugere outros nomes, e ficar sem créditos oferece uma forma de adicionar créditos.
Sites estáticos têm um limite por arquivo de cerca de 25 a 30 MB, dependendo do tipo de site, e até 20.000 arquivos. Arquivos grandes são melhor guardados no storage e vinculados a partir do site.
Publicações com falha anteriores a esta mudança não têm tipo, então mostram uma linha neutra em vez de um motivo específico.
Se “um problema do nosso lado” continuar acontecendo, entre em contato com o suporte com o ID do projeto e o nome do link.

A lista completa de mensagens e o que fazer em cada caso está em solução de problemas de publicação. Se você estiver corrigindo um app teimoso manualmente, nosso guia sobre como depurar um app criado com IA mostra o caminho. E para entender o que acontece com um site no ar enquanto você republica, veja seu app publicado agora continua no ar enquanto você o republica.