Real story: a feature-flag helper defaulted to `true` on error. A flag-service outage would have rolled out a half-built feature to 100% of users. Mesrai caught the unsafe default on the PR that introduced the catch.

The vulnerable diff

tslib/feature-flag.ts

// lib/feature-flag.ts (the buggy helper)
export async function isEnabled(key: string, userId: string): Promise<boolean> {
  // BUG: error → true. If flag service is down, EVERY feature ships.
  return await flags.get(key, { userId }).catch(() => true);
}

What is wrong

Feature flag defaults on error should always be the safe direction — the direction that preserves the pre-launch state. For new features, that's OFF. For deprecation flags (e.g., 'use old code path'), that might be ON. The general rule is: error → fall back to whatever the world looked like before the flag existed. Returning `true` always for any error is the opposite of safe; it means the flag service becomes a single point of failure for every feature.

The attack

Almost-incident:

textexploit

t+0:00 — PR proposes adding helper with catch(() => true).
t+0:00 — Mesrai flags as security-equivalent — unsafe default.
t+0:01 — Engineer pauses. Reviews fallback policy.
t+0:02 — Realizes: if flag service blips, the half-built dashboard
         flag would have rolled out to 100% of users.
t+0:03 — Refactors to default false + logging.

No incident, because the catch-all default was caught at PR.

Counterfactual: full launch of a half-built feature to 100% during the next flag-service blip.

Mesrai's review comment

textreview-comment.txt

mesraipilot · Bot · reviewed 1 min ago

[mesrai] [code-review] [Logic] [Unsafe-Default] [high]

`.catch(() => true)` means flag-fetch failure → feature enabled.
Wrong default direction.

Safe default for new features is OFF on error. Pre-deprecation flags
might be ON. The rule is: error → world-before-the-flag.

Fix:

  export async function isEnabled(key: string, userId: string): Promise<boolean> {
    try {
      return await flags.get(key, { userId });
    } catch (err) {
      log.error({ err, key }, "flag fetch failed; defaulting OFF");
      metrics.increment("feature_flag.fetch_failed");
      return false;
    }
  }

Surface the failure (logs + metric). Alert on sustained failures.
The flag service should be a transient dependency, not a launch
gate.

The fix

tslib/feature-flag.ts (fixed)

// lib/feature-flag.ts — fixed
export async function isEnabled(key: string, userId: string): Promise<boolean> {
  try {
    return await flags.get(key, { userId });
  } catch (err) {
    log.error({ err, key, userId }, "flag fetch failed; defaulting OFF");
    metrics.increment("feature_flag.fetch_failed");
    return false;
  }
}

Safe default OFF on error. Log + metric for observability. Surfacing the failure means the team notices it and the flag service stays healthy.

Why human review missed it

Feature flag fallback discipline is rarely audited. Mesrai catches `catch(() => true)` patterns in flag-fetch code.

Related rules + further reading

Mesrai rule pack: logic/feature-flag-safe-default — flags catch returning true on flag fetch.

LaunchDarkly / Statsig / Unleash all document safe-default discipline.

Common pre-incident pattern.

Takeaway

Safe defaults are the only defaults for feature flags. Error → off. Mesrai catches the unsafe pattern.

A Forgotten Feature Flag That Almost Shipped to 100% of Users