Jump to content

Connect Leeroopedia MCP: Equip your AI agents to search best practices, build plans, verify code, diagnose failures, and look up hyperparameter defaults.

Heuristic:Langfuse Langfuse Fail Open Resilience Pattern

From Leeroopedia
Knowledge Sources
Domains Resilience, Architecture
Last Updated 2026-02-14 06:00 GMT

Overview

Fail-open pattern used across Langfuse where optional features (S3 rate-limit detection, ingestion masking, Redis checks) return safe defaults on error rather than blocking the critical ingestion path.

Description

Langfuse's ingestion pipeline is the most critical path in the system: data loss is unacceptable. Several optional features enhance this path (rate-limit detection, data masking, caching), but if any of these features fail, the pipeline must continue processing data with original/unmasked/unoptimized behavior rather than dropping events. This fail-open pattern is explicitly coded in multiple locations with comments explaining the design choice.

Usage

Apply this heuristic when adding new optional features to the ingestion pipeline or any critical processing path. The rule is: if a feature is enhancement-only (not core to correctness), it should fail open. If a feature is correctness-critical (e.g., authentication), it should fail closed.

The Insight (Rule of Thumb)

  • Action: Return safe defaults (false, original data, empty) when optional feature checks fail.
  • Value: Zero data loss on the ingestion critical path; graceful degradation.
  • Trade-off: Optional features silently degrade rather than failing loudly. Requires monitoring/logging to detect degraded states.

Specific instances in Langfuse:

  1. S3 Slowdown Detection: Returns false on Redis error (don't redirect unnecessarily).
  2. Ingestion Masking (EE): Returns original unmasked data after retry exhaustion (fail-open mode).
  3. Redis Event Cache: Returns false on error (process event even if dedup check fails).
  4. Model Match Cache: Falls through to database query on cache miss or error.
  5. OTel Project Check: Returns false on Redis error (use FINAL modifier as safe default).

Reasoning

The reasoning differs by case:

S3 Slowdown: If Redis is unavailable, we cannot check slowdown flags. Routing all events to the primary queue (default) is the safest behavior. The alternative (routing to secondary) would starve the primary queue.

// From packages/shared/src/server/redis/s3SlowdownTracking.ts
export async function hasS3SlowdownFlag(projectId: string): Promise<boolean> {
  try {
    const result = await redis.get(key);
    return result === "1";
  } catch (error) {
    logger.error("Failed to check S3 slowdown flag", { projectId, error });
    return false; // Fail open - don't redirect unnecessarily
  }
}

Ingestion Masking: If the masking callback service is down, dropping events is worse than processing unmasked data. The enterprise customer can investigate and re-mask later.

// From packages/shared/src/server/ee/ingestionMasking/applyIngestionMasking.ts
if (attempt <= config.maxRetries) {
  await sleep(Math.min(Math.exp(attempt), 1000)); // Exponential backoff capped at 1s
  continue;
}
// Fail open: return success with original data
logger.warn("Ingestion masking failed, processing with original data (fail-open mode)");

Related Pages

Page Connections

Double-click a node to navigate. Hold to expand connections.
Principle
Implementation
Heuristic
Environment