joao.herculano
8c26c93732
@tanstack/start-server-core cria o defaultCsrfMiddleware de forma incondicional assim que o módulo carrega. Isso caía numa corrida de inicialização com o import circular que o nitro gera nos chunks de SSR (server-D-dARpA7.mjs <-> server-D-dARpA72.mjs), fazendo toda requisição no build de produção falhar com "createCsrfMiddleware is not a function". Reproduzido de forma determinística tanto com preset node-server quanto cloudflare-module, e com múltiplas versões do nitro — não é regressão de versão, é a inicialização eager em si colidindo com a ordem de avaliação do ciclo. Patch (via patch-package, reaplicado no postinstall) adia a criação do defaultCsrfMiddleware para dentro de uma função, eliminando a corrida sem mudar nenhum comportamento. Validado com reinstalação limpa de node_modules + build + smoke test em /healthz, / e /auth.
SLA Separacao
Aplicacao TanStack Start/Node.js para registro de coleta de pedidos, usando SQL Server.
Desenvolvimento local
npm install
npm run dev
Estrutura de deploy
Este repositorio ja possui a base para subir o app como servico separado:
- Dockerfile
- Jenkinsfile
- k8s/deployment.yaml
- k8s/service.yaml
- k8s/hpa.yaml
- k8s/secret.example.yaml
- k8s/create-secret.sh
Variaveis obrigatorias
O app precisa destas variaveis no ambiente de deploy:
DB_HOSTDB_PORTDB_NAMEDB_USERDB_PASSWORDDB_ENCRYPTDB_TRUST_SERVER_CERTDB_SERVER_NAMESESSION_SECRET
Antes do deploy
Voce precisa validar estes pontos no ambiente da empresa:
- O cluster/servidor consegue acessar
10.77.77.10:1433. - O registry
10.77.77.41:5000aceita push da nova imagem. - O namespace
ci-cde o padrao de deploy pelo Jenkins continuam validos. - A
nodePort30310esta livre, ou voce vai trocar para outra. - Existe uma forma de expor esse novo servico externamente depois do
Service.
Observacoes
- O app atual usa SQL Server direto, sem API intermediaria.
- O deploy criado aqui e separado do app Django existente.
- O repositório nao guarda o secret real de producao; ele deve ser criado no cluster.