Seu agente de IA na Elevare Digital ficou ocioso porque uma nova política de segurança de nível de linha (RLS) do PostgreSQL filtrou todas as linhas de tarefas, fazendo com que a fila parecesse vazia. O erro passou despercebido até que as tarefas se acumularam, forçando a equipe a redesenhar a forma como o orquestrador detecta uma fila vazia.

O ponto cego oculto

ARIA, o sistema de IA autônomo da Elevare, consulta uma tabela PostgreSQL em busca de tarefas pendentes. A consulta foi bem-sucedida, retornou zero linhas e o agente "adormeceu". Na realidade, a tabela estava cheia. Uma política de RLS limitou o acesso SELECT a um conjunto específico de usuários. O orquestrador conectou-se com uma service role que não possuía o privilégio de bypass, então o banco de dados removeu silenciosamente cada linha do conjunto de resultados. O PostgreSQL trata uma leitura filtrada da mesma forma que uma tabela vazia, portanto, nenhum erro, aviso ou código de falha apareceu. Um heartbeat saudável do agente ocioso não deu nenhuma pista de que algo estava errado.

Como o RLS transformou uma fila cheia em silêncio

O RLS adiciona um predicado a cada linha durante um SELECT. Se o predicado for falso, a linha desaparece do resultado. O cliente vê apenas as linhas que satisfazem a política; ele nunca sabe que linhas foram ocultadas. Para um worker de fila, um conjunto de resultados vazio parece exatamente com uma fila genuinamente vazia. O orquestrador assumiu que “nenhuma linha = nenhum trabalho” e entrou em seu loop de ociosidade enquanto as tarefas se acumulavam nos bastidores.

A equipe descobriu que uma política destinada a restringir as leituras a usuários individuais acabou atingindo, sem intenção, a própria service role. Como a função não possuía o atributo especial “bypass RLS”, a política foi aplicada a cada consulta emitida pelo orquestrador. Isso ilustra um clássico trade-off entre segurança e observabilidade: o RLS protege os dados de usuários não autorizados, mas também remove um sinal de falha útil para componentes do sistema que dependem de visibilidade.

O padrão canary-check

Para quebrar a dependência de um resultado vazio silencioso, a Elevare adicionou uma verificação “canário” (canary check). O novo fluxo é:

  1. Consultar a tabela de tarefas pendentes.
  2. Se linhas forem retornadas, processe-as como antes.
  3. Se o resultado estiver vazio, execute uma segunda consulta contra uma linha canário dedicada que deve sempre existir.
  4. Se a consulta canário retornar a linha esperada, a fila está realmente vazia; registre um heartbeat de ociosidade.
  5. Se a consulta canário também não retornar nada, o agente está “cego”; dispare um alerta imediato.

Agora o orquestrador distingue três estados:

  • Tarefas encontradas – processamento normal.
  • Sem tarefas, canário OK – período de ociosidade genuíno.
  • Sem tarefas, falha no canário – bloqueio de RLS oculto, disparar alerta.

A tabela canário é uma única linha que nunca muda. Configurá-la levou cerca de uma hora, mas elimina toda uma classe de falhas silenciosas.

O que as equipes devem fazer

Se você executa workers de fila contra o PostgreSQL ou um serviço hospedado baseado nele (como o Supabase), siga estas etapas:

  • Use uma credencial de service-role com a flag “bypass RLS”. Isso permite que os componentes do sistema vejam todas as linhas, independentemente das políticas de nível de usuário.
  • Audite as políticas de RLS em busca de permissões de bypass ausentes para service roles. Uma política que parece correta para usuários finais pode, sem querer, prender serviços internos.
  • Adicione uma tabela canário (ou uma linha equivalente sempre presente) e incorpore a verificação canário na lógica de ociosidade do worker. A consulta extra é barata e fornece uma rede de segurança clara.

O trade-off

O RLS continua sendo uma ferramenta poderosa para impor o acesso a dados de forma granular. Ele evita vazamentos acidentais de dados e suporta arquiteturas multi-tenant sem espalhar filtros de nível de aplicação por todo o código-fonte. A desvantagem é que ele pode ocultar falhas de componentes que esperam que um simples sinal de “nenhuma linha” signifique “nada a fazer”. O padrão canário não enfraquece o RLS; ele adiciona uma etapa de verificação leve que restaura a observabilidade.

Conclusão

Uma política de RLS oculta pode transformar uma fila movimentada em um beco sem saída silencioso, deixando agentes de IA ociosos enquanto o trabalho se acumula. Conceda às service roles o privilégio de bypass adequado e combine cada leitura de fila vazia com uma verificação canário; assim, as equipes podem manter seus trabalhadores autônomos confiáveis e evitar pontos cegos dispendiosos.