camilafagundesandCursor
6e23f1533b
O módulo usa a identidade Supabase, isola cada workspace e registra storage, TTL, runner e biblioteca XLSX como decisões ainda abertas. Co-authored-by: Cursor <cursoragent@cursor.com>
40 lines
1.4 KiB
Markdown
40 lines
1.4 KiB
Markdown
# PROMPT 11 — Redis, progresso, lock e resiliência
|
|
|
|
Use o MASTER CONTEXT e a implementação Redis existente do Elo Pro.
|
|
|
|
## Objetivo
|
|
|
|
Adicionar coordenação efêmera sem transformar Redis em fonte de verdade.
|
|
|
|
## Implementar
|
|
|
|
1. Namespace claro para chaves do Adaptador.
|
|
2. Lock por operação/usuário necessário para impedir processamento concorrente indevido.
|
|
3. TTL do lock com renovação/cleanup seguro para evitar deadlock.
|
|
4. Progresso efêmero em Redis quando trouxer benefício, mantendo status durável no PostgreSQL.
|
|
5. Idempotency key para disparo de processamento, se o padrão do repo suportar.
|
|
6. Query/polling/subscription da UI conforme arquitetura existente; TanStack Query deve invalidar/refetch adequadamente.
|
|
7. Fallback claro se Redis estiver indisponível: falha controlada ou degradação segura, nunca execução duplicada silenciosa.
|
|
|
|
## UX de progresso
|
|
|
|
- percentual somente se for real/estimável; não invente precisão falsa;
|
|
- estados textuais como “Validando”, “Processando”, “Gerando arquivo”;
|
|
- sucesso e erro persistentes o suficiente para o usuário agir;
|
|
- botão de processar desabilitado durante job ativo.
|
|
|
|
## Observabilidade
|
|
|
|
Tags de job ID e workspace ID técnico, sem dados de planilha.
|
|
|
|
## Testes
|
|
|
|
- lock adquirido;
|
|
- lock concorrente;
|
|
- expiração;
|
|
- erro de Redis;
|
|
- retry;
|
|
- progresso;
|
|
- refresh de página durante job;
|
|
- job concluído enquanto UI estava fechada.
|