Fixing a null-body crash in the Formbricks survey SDK, found by Sentry

Introduction

At 02:14 UTC, our Sentry dashboard spiked. A TypeError: Cannot read properties of null (reading 'questions') was bubbling up from the Formbricks survey SDK across multiple production deployments. The error rate jumped by 3.8% in under six minutes, affecting users across Safari, Chrome, and Firefox.

The crash wasn’t triggered by a race condition, a memory leak, or a dependency conflict. It was caused by a missing null check on an HTTP response body. A reverse proxy in one of our user environments was returning a 204 No Content response for a configuration endpoint that the SDK assumed would always return JSON. When the SDK called response.json() on an empty stream, the browser threw a SyntaxError, which our error boundary caught, but the subsequent fallback logic tried to access config.questions on a null state, hard-crashing the widget and leaving a broken DOM node in the host application.

This article details how we traced the anomaly, why TypeScript types failed to catch it at runtime, and the defensive architecture we implemented to patch the SDK core. We also cover the observability patterns that turned a noisy error stream into a actionable fix.

Why This Matters

SDKs are the contract between your service and your users’ browsers. Unlike backend services, SDKs operate in untrusted, fragmented environments. You cannot control the network stack, the proxy configuration, or the host application’s lifecycle. A crash in an SDK doesn’t just break your feature; it pollutes the host app’s console, risks blocking the main thread, and erodes developer trust.

Sentry exposed this issue because we had configured proper error grouping and breadcrumb tracking. Without that observability layer, this crash would have been buried in generic TypeError noise, slowly degrading user experience until a manual support ticket surfaced it. For any team shipping frontend libraries, treating network responses as hostile by default and instrumenting failures with context is non-negotiable.

How It Works

The Formbricks SDK fetches survey configurations asynchronously upon initialization. The request lifecycle flows through a client layer that handles authentication, caching, and response parsing. Before the fix, the pipeline assumed all 2xx responses contained a valid JSON payload. The patch introduces a defensive validation gate that intercepts the response stream, verifies body presence, and enforces schema integrity before the data reaches the rendering engine.

The following diagram illustrates the corrected request pipeline and how Sentry instrumentation captures edge cases without disrupting the host application:

flowchart TD
    subgraph SDK_Architecture
        A[SurveyClient Init] --> B[Fetch Config Request]
        B --> C{HTTP Status Check}
        C -->|!2xx| D[Throw NetworkError]
        C -->|2xx| E