MoWave One: FeatureGate.EXTERNAL_EVENTS_ACTIVE sem uso

Nesta semana, quero compartilhar uma descoberta recente de uma auditoria sistemática que a gente conduziu no MoWave One. A gente encontrou um problema sutil envolvendo FeatureGate.EXTERNAL_EVENTS_ACTIVE, um feature gate criado para limitar o número de eventos externos do Google Calendar que os usuários podiam sincronizar no app Lima. Este gate em particular foi declarado com limites: usuários Free deveriam ser limitados a 5 eventos, usuários Trial a 25, e usuários Pro teriam acesso ilimitado. O problema, como se descobriu, é que esses limites nunca foram realmente aplicados.

O Problema: Um Gate sem Cerca

O problema se manifestou como um feature gate declarado que oferecia uma falsa sensação de segurança. Durante a auditoria, a gente descobriu que FeatureGate.EXTERNAL_EVENTS_ACTIVE estava de fato definido. Sua declaração estava na linha 124 de FeatureGate.java, descrevendo claramente os limites pretendidos para as diferentes tiers de planos. No entanto, uma análise aprofundada da base de código revelou uma omissão crítica: não havia nenhum call site para este gate. Isso significa que nenhum código jamais invocou canUse ou lockSnapshotMutation com FeatureGate.EXTERNAL_EVENTS_ACTIVE.

Considere um usuário Trial, por exemplo. A intenção era limitá-lo a 25 eventos sincronizados. Mas como o gate nunca foi realmente verificado, um usuário Trial poderia sincronizar muito mais eventos sem nenhuma impedância em nível de sistema. O gate declarado na nossa base de código parecia uma salvaguarda durante as code reviews, dando a impressão de que um limite estava em vigor, enquanto, na realidade, ele era completamente não aplicado. Esse tipo de gate declarado mas não utilizado é, de certa forma, pior do que não ter gate algum. Ele cria uma ilusão de proteção sem fornecer nenhuma.

A Causa Técnica: Declaração Sem Implementação

A causa técnica era direta: uma desconexão entre declaração e implementação. O gate foi corretamente declarado como parte do nosso sistema de feature gating, mas a lógica da aplicação responsável por aplicar os limites simplesmente não existia. Não havia um if (featureGateService.canUse(FeatureGate.EXTERNAL_EVENTS_ACTIVE, currentUser)) ou construção similar em qualquer parte do caminho do código que lidava com a sincronização de eventos. A lógica para verificar o limite, impedir novas adições de eventos ou até mesmo notificar o usuário sobre o atingimento de um limite estava completamente ausente. O gate era uma entrada de metadados inerte, nunca interagindo com o comportamento em runtime da aplicação.

A Correção: Decisão de Produto, Não Aplicação Silenciosa

Nossa abordagem para corrigir isso foi deliberada. A gente poderia, em teoria, ter adicionado silenciosamente as verificações de canUse e começado a aplicar os limites descritos por FeatureGate.EXTERNAL_EVENTS_ACTIVE. No entanto, adicionar silenciosamente um limite que ninguém havia explicitamente concordado como uma decisão de produto parecia errado. Em vez disso, a gente optou por documentar a descoberta minuciosamente e marcá-la como um ponto de decisão de produto. As opções apresentadas à equipe de produto eram claras: ou aplicar os limites existentes conforme declarado, ou formalmente remover o gate se esses limites não fossem mais desejados ou relevantes. Isso garante que qualquer mudança na experiência do usuário, especialmente uma que envolva uma redução na funcionalidade para certas tiers, seja uma escolha consciente de produto, e não uma correção técnica silenciosa.

Este incidente destaca a importância de não apenas declarar features ou limites, mas também garantir rigorosamente que eles estejam integrados ao código operacional real. Para o MoWave One e o app Lima (sobre o qual você pode aprender mais em https://getlima.app), manter altos padrões para nossa base de código é fundamental, e esses tipos de auditorias são inestimáveis.

Takeaways

O principal takeaway dessa experiência é simples, mas crítico: sempre faça um grep nos seus feature flags para encontrar call sites, e não apenas suas declarações. Um feature gate ou qualquer mecanismo de controle similar, não importa quão bem definido em sua declaração, oferece uma falsa sensação de segurança se nunca for realmente invocado pela lógica da aplicação. Garanta que todo gate declarado tenha call sites ativos e verificáveis aplicando seu comportamento pretendido.