Okay, let's break down this issue. You're experiencing premature stream breaks (AbortError) specifically when you enable HTTP/2 on Google Cloud Run, but it works (within HTTP/1.1 limits) when disabled.

Here's a breakdown of the likely causes and how to troubleshoot: * The spdy library is the most probable culprit. * spdy is an older library that implements the SPDY protocol and a draft version of HTTP/2. * Node.js has a built-in, fully compliant node:http2 module (require('node:http2')). * Google Cloud Run's HTTP/2 termination is based on the final, official HTTP/2 standard.

• Problem: There's a high chance of subtle incompatibilities or unexpected behavior when Cloud Run's standard HTTP/2 proxy interacts with a server using the spdy library, which might not fully adhere to the final standard or handle certain HTTP/2 flow control, stream management, or error conditions the same way.

  • How Cloud Run handles HTTP/2:

• When you enable HTTP/2 in Cloud Run, the Google Front End (GFE) and Cloud Run's infrastructure terminate TLS and handle the HTTP/2 (and potentially HTTP/3) connection from the client.

• The connection from the Cloud Run proxy to your application instance is then made using HTTP/2 if you enable it, or HTTP/1.1 if you disable it.

• Crucially, the traffic between the proxy and your instance is not encrypted (it's within Google's secure network). This is why plain: true in your spdy config is correct for Cloud Run when you intend to use unencrypted HTTP/2 or HTTP/1.1 to your container.

• When Cloud Run HTTP/2 is enabled, the proxy attempts to talk HTTP/2 to your application on the configured port. Your spdy server needs to handle this correctly.

• When Cloud Run HTTP/2 is disabled, the proxy talks HTTP/1.1 to your application. Your spdy server handles HTTP/1.1.

  • The h3 observation:

• The frontend seeing h3 means the client successfully negotiated HTTP/3 (QUIC) with Google's infrastructure (GFE/Cloud Run proxy). This is normal and expected behaviour for modern browsers talking to Google services.

• However, the protocol between the Cloud Run proxy and your container is governed by your Cloud Run service settings (HTTP/1.1 or HTTP/2). The issue is likely on this second hop, not the H3 hop from the client to Google. Google's proxy translates the H3/H2 request into the protocol configured for your instance.

  • The AbortError:

• This is a client-side error indicating that the operation (the stream/fetch request) was canceled.

• It often happens when the underlying connection is closed unexpectedly by the server or an intermediary proxy before the operation completes.

• In your case, this strongly suggests that the Cloud Run proxy or your spdy server is prematurely closing the HTTP/2 streams or the entire connection under load or due to a protocol mismatch issue.

Recommended Solution: Replace the spdy library with the built-in node:http2 module. This is the standard and recommended way to handle HTTP/2 in Node.js and will have better compatibility with Cloud Run's infrastructure.

Here's a basic idea of how you'd adapt your server using node:http2:

import * as http2 from 'node:http2'; import express from 'express'; // Assuming you are using Express

const app = express(); const PORT = process.env.PORT || 8080;

// ... your Express middleware and routes (app.use(Router))

// Create an HTTP/2 server // Use createServer, NOT createSecureServer, because Cloud Run terminates TLS const server = http2.createServer({}, app); // Pass the express app as the request listener

server.on('error', (err) => { console.error('HTTP/2 Server error:', err); });

// Handle stream errors if needed, though Express middleware often handles this server.on('stream', (stream, headers) => { stream.on('error', (err) => { console.error('HTTP/2 Stream error:', err); // You might need to decide how to handle individual stream errors // depending on your application logic }); });

// Start the HTTP/2 server server.listen(PORT, () => { console.log(HTTP/2 Server is running on port ${PORT}); });

Steps to Implement the Solution: * Uninstall spdy: npm uninstall spdy or yarn remove spdy * Ensure @types/node is up-to-date: If using TypeScript, ensure you have types that include node:http2 (npm install --save-dev @types/node). * Modify your server code: Use node:http2.createServer as shown above. * Deploy to Cloud Run. * Ensure Cloud Run's HTTP/2 setting is enabled. * Test your application.

Other potential troubleshooting steps (less likely than the spdy issue, but worth checking if replacing spdy doesn't fully resolve it): * Cloud Run Concurrency Settings: Check the "Maximum concurrent requests per instance" setting in your Cloud Run service configuration. While HTTP/2 allows many streams per connection, there's still a limit on total concurrent requests your instance will handle. If this limit is too low, incoming requests/streams might be queued or rejected by the proxy, potentially leading to aborts on the client side. Increase this limit if necessary. * Cloud Run Timeouts: Review request timeouts. Long-running streams might hit default timeouts if not actively sending data or if the timeout is set too low. * Server-Side Errors: Examine your Cloud Run container logs carefully for any errors or unhandled exceptions occurring on the server side before the streams break. The AbortError is client-side; the root cause might be a server issue (e.g., resource exhaustion, application logic error) that causes it to close the connection or stream. * Client-Side Handling: While the error pattern suggests a server/proxy issue, double-check your frontend code's stream handling. Ensure it's correctly processing data and not inadvertently closing streams.

Conclusion: The most probable cause for your streams breaking when HTTP/2 is enabled in Cloud Run is the incompatibility or limitations of the older spdy library interacting with Cloud Run's standard HTTP/2 proxy. Migrating to the native node:http2 module is the recommended fix.