MoWave One Audit: Unused FeatureGate.EXTERNAL_EVENTS_ACTIVE

This week I want to share a recent discovery from a systematic audit we conducted at MoWave One. We found a rather subtle issue involving FeatureGate.EXTERNAL_EVENTS_ACTIVE, a feature gate intended to cap the number of external Google Calendar events users could sync within the Lima app. This particular gate was declared with limits: Free users were meant to be capped at 5 events, Trial users at 25, and Pro users had unlimited access. The problem, as it turned out, was that these limits were never actually enforced.

The Problem: A Gate with No Fence

The issue manifested as a declared feature gate that offered a false sense of security. During our audit, we discovered that FeatureGate.EXTERNAL_EVENTS_ACTIVE was indeed defined. Its declaration sat at FeatureGate.java line 124, clearly outlining the intended caps for different plan tiers. However, a deep dive into the codebase revealed a critical omission: there were zero call sites for this gate. This means no code ever invoked canUse or lockSnapshotMutation with FeatureGate.EXTERNAL_EVENTS_ACTIVE.

Consider a Trial user, for example. The intention was to cap them at 25 synced events. But because the gate was never actually checked, a Trial user could sync far more events without any system-level impedance. The declared gate in our codebase read like a safeguard during code reviews, giving the impression that a limit was in place, while in reality, it was completely unenforced. This kind of declared-but-unused gate is, in some ways, worse than having no gate at all. It creates an illusion of protection without providing any.

The Technical Cause: Declaration Without Implementation

The technical cause was straightforward: a disconnect between declaration and implementation. The gate was properly declared as part of our feature gating system, but the application logic responsible for applying the limits simply didn’t exist. There was no if (featureGateService.canUse(FeatureGate.EXTERNAL_EVENTS_ACTIVE, currentUser)) or similar construct anywhere in the code path that handled event synchronization. The logic to check against the limit, prevent new event additions, or even notify the user about hitting a cap was entirely absent. The gate was an inert metadata entry, never interacting with the application’s runtime behavior.

The Fix: Product Decision, Not Silent Enforcement

Our approach to fixing this was deliberate. We could have, in theory, silently added the canUse checks and started enforcing the limits described by FeatureGate.EXTERNAL_EVENTS_ACTIVE. However, silently adding a limit that nobody had explicitly agreed on as a product decision felt wrong. Instead, we chose to document the finding thoroughly and flag it as a product decision point. The options presented to the product team were clear: either enforce the existing limits as declared, or formally drop the gate if those limits were no longer desired or relevant. This ensures that any change in user experience, especially one involving a reduction in functionality for certain tiers, is a conscious product choice rather than a technical quiet fix.

This incident highlights the importance of not just declaring features or limits, but also rigorously ensuring they are integrated into the actual operational code. For MoWave One and the Lima app (which you can learn more about at https://getlima.app), maintaining high standards for our codebase is paramount, and these kinds of audits are invaluable.

Takeaways

The key takeaway from this experience is simple yet critical: always grep your feature flags for call sites, not just their declarations. A feature gate or any similar control mechanism, no matter how well-defined in its declaration, provides a false sense of safety if it’s never actually invoked by the application logic. Ensure that every declared gate has active, verifiable call sites enforcing its intended behavior.