camilafagundesandClaude Opus 5
b972589949
`next start` força NODE_ENV=production, então homologação não tinha como se distinguir de produção: o login local ficava desligado (correto) e o módulo exigia o SSO do Elo Pro, que ainda não existe. Não havia terceiro caminho. - `ADAPTER_ENV` com development, staging e production, independente de NODE_ENV. Toda política passa a derivar dele. - Fail-fast de configuração em `fail-fast.ts`, separado de `env.ts` porque `process.exit` não existe no Edge Runtime. - `requireDatabaseUrl` elimina o fallback silencioso para PGlite: um segredo ausente em staging migrava um arquivo local e parecia sucesso. - Shim de identidade passa a ser decisão explícita via `ADAPTER_APPLY_IDENTITY_SHIM`; aplicá-lo sobre o schema real do Elo Pro é destrutivo em potencial. - `migration-manifest.ts` responde o estado do schema consultando só o banco. Ler o diretório numa rota fazia o Next tracear o projeto inteiro para a saída standalone, levando docs, testes e fontes para a imagem. - Redis e Supabase viram singleton por processo. Criar um ioredis por requisição vazava conexão: o cliente é lazy, abre no primeiro uso e nunca fecha. - Namespace de chaves deriva de ADAPTER_NAMESPACE e do ambiente lógico, não de SENTRY_ENVIRONMENT. Observabilidade e isolamento de dados são decisões diferentes, e a variável única fazia homologação e produção colidirem. - Listagem do bucket passa a paginar e descer em subpastas. Parando em 1000 entradas, a limpeza por TTL deixava de ver arquivos e temporários venciam sem nunca ser removidos. - `ping` e `hit` no coordenador, e `healthcheck` no armazenamento, para o health check tocar as dependências de verdade. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
43 lines
1.4 KiB
TypeScript
43 lines
1.4 KiB
TypeScript
import path from "node:path";
|
|
import { isDeployedEnv } from "@/config/env";
|
|
import { LocalPrivateStorage } from "./local";
|
|
import { createSupabaseStorage } from "./supabase";
|
|
import type { ObjectStorage } from "./memory";
|
|
|
|
let singleton: ObjectStorage | null = null;
|
|
let singletonKey: string | null = null;
|
|
|
|
/**
|
|
* Armazenamento reutilizado pelo processo. O cliente Supabase mantém pool
|
|
* de conexões HTTP: criar um por requisição desperdiça soquete.
|
|
*/
|
|
export function createStorage(): ObjectStorage {
|
|
const url = process.env.NEXT_PUBLIC_SUPABASE_URL;
|
|
const serviceKey = process.env.SUPABASE_SERVICE_ROLE_KEY;
|
|
const bucket = process.env.SUPABASE_STORAGE_BUCKET;
|
|
const key = `${url ?? ""}|${bucket ?? ""}|${serviceKey ? "svc" : "nosvc"}`;
|
|
if (singleton && singletonKey === key) return singleton;
|
|
|
|
if (url && serviceKey && bucket) {
|
|
singletonKey = key;
|
|
singleton = createSupabaseStorage(url, serviceKey, bucket);
|
|
return singleton;
|
|
}
|
|
if (isDeployedEnv()) {
|
|
throw new Error(
|
|
"Armazenamento privado não configurado. Defina NEXT_PUBLIC_SUPABASE_URL, SUPABASE_SERVICE_ROLE_KEY e SUPABASE_STORAGE_BUCKET.",
|
|
);
|
|
}
|
|
singletonKey = key;
|
|
singleton = new LocalPrivateStorage(path.join(process.cwd(), ".data", "storage"));
|
|
return singleton;
|
|
}
|
|
|
|
/** Usado em testes para não vazar estado entre casos. */
|
|
export function resetStorage(): void {
|
|
singleton = null;
|
|
singletonKey = null;
|
|
}
|
|
|
|
export type { ObjectStorage };
|