Why Google Pub/Sub breaks silently in Bun

The Symptom: “undefined undefined undefined”

I spent days debugging this error:

1
Error: undefined undefined: undefined
2
    at callErrorFromStatus
3
    at onReceiveStatus
4
    at makeUnaryRequest

Or sometimes:

1
Exception occurred in retry method that was not classified as transient

Everything looked correct:

• Pub/Sub initialized successfully
• Topics existed
• IAM permissions were correct
• gcloud CLI worked perfectly
• A minimal Node.js script workedmmediately

Yet my Bun app kept failing.

The Setup

Runtime: Bun
Library: @google-cloud/pubsub
Transport: default (gRPC)
Environment: Docker + local dev
Credentials: ADC + service account JSON

The client initialization looked textbook:

1
this.pubsub = new PubSub({
2
  projectId: config.pubsub.projectId,
3
});

This is exactly what Google’s documentation recommends.

And yet… it failed. Every time.

The Breakthrough: fallback: true

Out of desperation, after reading some Bun issues, I tried this:

1
this.pubsub = new PubSub({
2
  projectId: config.pubsub.projectId,
3
  fallback: true,
4
});

Suddenly:

• Messages published successfully
• Retries worked
• No more “undefined undefined: undefined”
• No more gRPC stack traces

One flag. Everything worked.

So what was happening?

What fallback: true Actually Does

Google Pub/Sub supports two transports:

1. gRPC (default) — Fast, binary, HTTP/2
2. REST/HTTP+JSON — Slower, more compatible

When you set fallback: true, you’re saying:

“Do NOT use gRPC. Use REST instead.”

That single boolean switches the entire transport layer.

Why gRPC Breaks in Bun

The Core Issue

Bun does not fully support Node’s native gRPC stack.

Google Pub/Sub depends on:

• @grpc/grpc-js
• HTTP/2 primitives
• Low-level socket handling
• Node-specific stream internals

Bun:

• Implements many Node APIs
• But not all edge cases
• Especially around HTTP/2 + gRPC interactions

Result: Things break silently.

gRPC Errors Lose Their Metadata

Instead of a proper error like:

1
PERMISSION_DENIED
2
UNAVAILABLE
3
DEADLINE_EXCEEDED

You get:

1
undefined undefined: undefined

Why?

1. gRPC status codes aren’t mapped correctly in Bun
2. Bun drops or mis-parses response trailers (metadata)
3. Error details never reach the client
4. Retry logic says: “This error isn’t transient… but I don’t know what it is”

The result is a completely unhelpful error message.

The Failure Mode Is Silent and Misleading

This is the worst part.

From the outside, it looks like:

• Bad IAM permissions
• Missing credentials
• Broken topic
• Pub/Sub outage

But none of those are true.

Your app is fine.
Your config is fine.
Your cloud setup is fine.

The runtime is the problem.

And you won’t know it until you’ve already spent a day debugging IAM policies.

Why Node.js Works Instantly

When I ran the same code with Node:

GOOGLE_APPLICATION_CREDENTIALS=./sentinel-sa.json node test-pubsub.js

It worked immediately. No changes. No flags.

Why?

1. Node has first-class support for gRPC
2. Google SDKs are tested primarily against Node
3. HTTP/2 and stream semantics are stable
4. Error handling is correct

This is why Google’s documentation always says:

“Node.js runtime”

—not “JavaScript runtime”.

The Performance Tradeoff

gRPC vs REST: Real Numbers

gRPC benchmarks consistently show:

• 7–10× faster throughput than REST
• 6× higher requests per second in equivalent services
• Lower CPU usage due to binary encoding and HTTP/2

What This Means

gRPC (default):

• Best for high-throughput, latency-sensitive workloads
• Works perfectly in Node.js
• Breaks mysteriously in Bun

REST fallback:

• Works in any HTTP-capable runtime
• Simple, predictable error handling
• 5–10× slower throughput
• Higher latency

For most workloads, the performance difference is acceptable. Especially for:

• Log pipelines (throughput is moderate)
• Background jobs (latency isn’t critical)
• Monitoring agents (reliability > speed)

Why Bun Isn’t Ready for Google Pub/Sub (Today)

Bun is fantastic for:

• REST APIs
• Edge services
• Frontend tooling
• Fast dev loops

But it’s not ready for:

• gRPC-heavy SDKs
• Deep cloud integrations
• Google Cloud client libraries

Specifically, these GCP services rely on gRPC:

• Pub/Sub ← Don’t use gRPC in Bun
• Bigtable ← Use fallback
• Spanner ← Use fallback
• Firestore (gRPC path) ← Use fallback

The issue isn’t unique to Pub/Sub. It’s systemic to how Bun handles gRPC.

Recommended Patterns

If You Insist on Bun

1
import { PubSub } from '@google-cloud/pubsub';
2

3
const pubsub = new PubSub({
4
  projectId: process.env.GCP_PROJECT_ID,
5
  fallback: true, // REQUIRED in Bun
6
});
7

8
const topic = pubsub.topic(process.env.PUBSUB_TOPIC_NAME!);
9

10
// Now this works
11
await topic.publishMessage({
12
  json: { message: 'hello' },
13
});

Additional considerations:

• Expect slightly higher latency (5–10×)
• Avoid very high message throughput (100k+ msgs/sec)
• Monitor publish timings
• Use for: background jobs, log pipelines, internal tools

If You’re Building Infrastructure

Use Node.js.

Seriously.

Especially if:

• Pub/Sub is core to your system
• Retries matter
• You need predictable error handling
• Throughput is important

Lessons Learned

1. Not all “Node-compatible” runtimes are cloud-SDK-compatible

   • Bun passes 99% of Node tests
   • But gRPC is that 1%

2. gRPC is fragile outside Node

   • It’s deeply integrated with Node internals
   • Other runtimes need explicit support

3. Google SDKs assume Node semantics

   • Not JavaScript semantics
   • There’s a difference

Final Thoughts

This bug cost me days because:

1. Nothing was technically wrong
2. Logs were misleading
3. Failures looked like infra issues
4. The solution was a single flag

But here’s the deeper lesson:

When building on cloud infrastructure, match your runtime to the platform.

Bun is a fantastic runtime. But it’s not ready for gRPC-heavy Google Cloud SDKs.

…and you want low-friction, reliable deployment:

Use Node.js.

Further Reading

• Google Cloud Pub/Sub
• Github issue related to this problem
• gRPC vs REST Benchmarks
• @google-cloud/pubsub npm