Diagnóstico das integrações de uma loja

O healthcheck é um diagnóstico por loja, não um mecanismo de ativação automática nem prova de funcionamento de toda a aplicação. Ele não muda o status comercial da loja e não substitui a validação de uma conversa, compra ou entrega real.

Básico e completo

Tipo	Verificações	Efeitos
Básico (padrão, inclusive no cadastro automático)	DNS do e-mail, API WooCommerce, configuração Meta, vínculo do catálogo e disponibilidade/contagem do índice	Consultas; não cria produtos, pedidos, links de pagamento nem mensagens WhatsApp.
Completo (manual, com confirmação)	Os itens básicos mais cálculo de frete, checkout Mercado Pago e teste do telefone administrador	Cria produtos sintéticos ocultos, pode criar pedido/link e enviar mensagem WhatsApp. Pode acionar webhooks e automações externas.

O teste completo não confirma pagamento aprovado ou entrega real. Apagar o pedido/produto não desfaz necessariamente notificações ou automações de outros sistemas. Preferir loja de teste e coordenar o uso em produção com o responsável.

Reexecutar pendências considera falhas, avisos e itens não verificados do tipo selecionado. Os demais resultados vêm do histórico e não foram revalidados. Para testar todas as configurações novamente, executar uma verificação do zero. Cada check selecionado executa de verdade: não reutiliza sucesso antigo do cache.

Verificar uma integração por vez

Cada item do painel tem um botão Verificar. Ele executa somente aquela verificação, mesmo que o seletor do conjunto esteja em "Teste completo". Os resultados dos outros itens são preservados e identificados como anteriores; não devem ser tratados como uma nova validação. Sem histórico, permanecem não verificados.

• E-mail, conexão WooCommerce, configuração WhatsApp, catálogo e índice de produtos fazem apenas consultas.
• Frete, pagamento e WhatsApp do administrador pedem confirmação específica antes de executar. Cancelar não inicia o teste.
• Frete e pagamento dependem das credenciais/configurações do WooCommerce, mas não executam o check de conexão como um teste separado. Não é preciso executar e-mail, Meta ou IA antes deles.
• O teste do administrador utiliza o WhatsApp central da EcomSmart, não o número da loja. O catálogo depende da conta Meta; o índice depende da sincronização de produtos. As instruções aparecem em O que precisa estar configurado?.

Só é permitida uma execução por loja por vez. Durante a execução, os outros botões ficam desabilitados. Se outra sessão já iniciou um diagnóstico, o painel acompanha o existente e informa isso, sem enfileirar o novo teste. Uma reserva de segurança de uma execução concluída com ações incertas retorna conflito e pede que se aguarde, sem repetir ações silenciosamente.

O que significa o prazo de 24 horas do WhatsApp?

A Meta permite responder com texto comum durante as 24 horas seguintes à última mensagem enviada pelo contato ao número WhatsApp da empresa. Cada nova mensagem desse contato reinicia o prazo. Fora dele, a empresa precisa usar uma mensagem-modelo aprovada pela Meta (template), e não texto livre. É uma regra de envio, não uma indicação de que o telefone está errado. Veja a política oficial do WhatsApp Business.

O teste do telefone administrador envia texto comum. Para executá-lo, o administrador deve mandar um "oi" ao WhatsApp central da EcomSmart, e então selecionar Verificar nesse item. Mandar mensagem ao WhatsApp da loja não abre esse prazo com o número central. Rejeição por esse motivo aparece como atenção, nunca como entrega confirmada. O teste não envia template automaticamente para contornar a restrição.

Como interpretar os resultados

• OK: a verificação específica passou, dentro do alcance descrito.
• Falha: foi identificado um problema que exige correção.
• Atenção: resultado incompleto ou inconclusivo, como timeout, envio não confirmado ou frete sem cotação do Melhor Envio.
• Não verificado: teste não executado ou recurso opcional ausente. Catálogo Meta não configurado é opcional; outros itens não confirmados impedem o diagnóstico geral de ficar totalmente OK.

A aprovação não confirmada do template impede o check Meta de ficar OK. A inscrição do aplicativo na WABA não comprova recebimento do webhook. O catálogo é validado por leitura e vínculo, sem mensagem para número fictício, usando GET /{waba_id}/product_catalogs do SDK oficial da Meta.

O check do índice não faz busca semântica nem valida chaves dos modelos. E-mail consulta DNS, não caixa postal ou SMTP. O telefone distingue envio aceito, entrega confirmada e rejeição pela janela de atendimento.

A consulta do índice também não inicializa, migra ou exclui coleções, nem cria tenants no Weaviate. Coleção ausente ou incompatível precisa ser tratada na rotina de indexação/provisionamento, não pelo healthcheck.

Execução compartilhada e interrupções

O Redis existente mantém snapshots por 24 horas sob platform-api:hc:v2:. PostgreSQL mantém o último resultado por loja. Não há novo worker de infraestrutura: a tarefa executa na réplica que a iniciou, mas qualquer réplica pode acompanhar o estado.

Uma reserva atômica permite apenas uma execução por loja. Solicitações simultâneas acompanham o mesmo job. Há heartbeat a cada 15 segundos; após 90 segundos sem heartbeat, uma consulta pode marcar interrupção. Ações externas não são repetidas automaticamente, nem retomadas após restart.

A reserva dura até 15 minutos. Se um teste completo perder o trabalhador ou terminar com efeitos incertos, ela é mantida até expirar. Isso evita repetir checkout enquanto uma resposta externa pode estar atrasada. Um básico interrompido pode liberar a reserva, pois só consulta dados. Não apagar essas chaves para contornar o bloqueio sem investigar.

Cada check tem até sete minutos no orquestrador, com limite global de oito minutos; o painel acompanha por até oito minutos e meio. Testes WooCommerce têm limite de três minutos para a simulação, além da limpeza. Chamadas síncronas executam fora do loop assíncrono. Falha de armazenamento aparece como aviso, não sucesso; Redis indisponível impede iniciar novos testes.

O banco compara o início das execuções para impedir que um trabalhador antigo sobrescreva resultado mais recente. A conclusão normal só é publicada depois da persistência.

Artefatos e frete

Produtos sintéticos têm SKU ecomsmart-hc-* e nome iniciado por [EcomSmart Healthcheck]. A sincronização incremental e completa não os indexa como produtos reais. Produtos comuns ocultos não são excluídos por essa regra.

A limpeza tenta todos os artefatos localizados, mesmo quando uma exclusão falha. Gravação com resposta perdida e sem confirmação posterior não é considerada limpa. O aviso conserva o motivo original e orienta a conferência manual. Reinício abrupto pode deixar efeitos que exigem intervenção; não há garantia de desfazer ações externas.

O endereço do frete é usado completo. Se faltar endereço no cadastro, usa-se o padrão completo de São Paulo, registrado nos logs, sem misturar CEP com outro estado. Cobertura de outras regiões exige validação própria. Frete grátis ou taxa fixa não comprovam funcionamento do Melhor Envio: é preciso identificar uma modalidade desse plugin.

Publicação segura

1. Revisar o MR, executar testes e construir imagens.
2. Executar a migration q3r4s5t6u7v8 antes dos serviços novos. Ela amplia apenas o constraint de status de platform.healthcheck_results para aceitar warning. A esteira normal executa migrations; não usar SKIP_DATABASE_MIGRATION=true na primeira publicação.
3. Evitar diagnósticos durante o rollout: versões antigas não conhecem os novos contratos/estado compartilhado.
4. Validar primeiro o básico após o rollout. Só executar o completo com autorização para efeitos na loja.
5. Conferir logs por loja, horário, request ID e job ID, sem copiar credenciais para tickets.

O downgrade converte avisos em falha, inclusive nos checks persistidos. Rollback somente de imagem para uma versão que desconhece warning pode não ler esses resultados; revisar compatibilidade antes de voltar. Downgrade de banco exige planejamento, não deve ser automático. Snapshots Redis novos também possuem o contrato novo e expiram após 24 horas.

Testes locais

Há regressões de concorrência, seleção vazia, confirmação de efeitos, conclusão/persistência, estados inconclusivos, acompanhamento, cotação de frete e limpeza. Testes Lua reais usam Redis local descartável, prefixo único e sem FLUSHDB.

Para executá-los na suíte do Platform API, definir TEST_HEALTHCHECK_REDIS_URL para Redis de testes em 127.0.0.1 ou localhost. Nunca usar produção. Sem a variável, somente esses testes de integração Redis são ignorados; as regressões unitárias continuam na esteira.