Hello,
Has anyone tested or worked with the response header : 'Transfer-Encoding' to obtain it as a response header in a service deployed in Cloud Run ?
I can't find it in my API response headers, if I create any other custom header I can get it.
Backend : NestJS
Best regards
Based on this Google Cloud Blog:
Cloud Run can now run gRPC services with server-streaming RPCs and send partial responses in a single request—in addition to existing support for unary (non-streaming) RPCs.
You could test this sample gRPC server application provided from the blog that you can test to stream responses from the Cloud Run-based serverless application.
Hi guys,
I have the same issue, please give me some clue to debug what is wrong.
Backend: Nest.js (10.4.7)
Cloud: Cloud Run behind Google Frontend
Code part:
@Post('/')
async chat(@Body() chatRequestBody: TheType, @Res() response: express.Response) {
// ... some secret code, pretty much data processing
// Manually handle the response as a streaming text endpoint
response.setHeader('Content-Type', 'text/plain');
response.setHeader('Transfer-Encoding', 'chunked');
// Force Google Frontend to enable chunked response
response.setHeader('x-goog-response-info', 'disable-response-buffering');
response.setHeader('Cache-Control', 'no-store, no-cache, must-revalidate, proxy-revalidate');
response.removeHeader('Content-Length');
response.flushHeaders();
try {
for await (const chunk of chatResponse.partialObjectStream) {
logger.debug(`Received chunk: ${JSON.stringify(chunk)}`);
response.write(JSON.stringify(chunk));
}
} catch (error: any) {
response.status(400).json({ type: 'error', error: error.message });
return;
}
response.end();
}
What I see from logs from Cloud Run is that each chunk is processed correctly, so I see something like:
Received chunk: {"chat":["Okay, I've reviewed the"]}
Received chunk: {"chat":["Okay, I've reviewed the message here is what I think"]}
But client gets response without `Transfer-Encoding: chunked`
Basically this:
vary | Origin |
access-control-allow-credentials | true |
x-request-id | *** |
content-type | text/plain |
x-goog-response-info | disable-response-buffering |
cache-control | no-store, no-cache, must-revalidate, proxy-revalidate |
X-Cloud-Trace-Context | *** |
Date | Tue, 14 Jan 2025 19:06:01 GMT |
Server | Google Frontend |
Content-Length | 1980 |
Alt-Svc | h3=":443"; ma=2592000,h3-29=":443"; ma=2592000 |
@robertcarlos wrote:
So, according to the post (from October 7, 2020), it should work right, why it does not?
Thanks.
I wrote then server-side events implementation, but it still returns one big chunk.
So according to this article I am using WebSockets right now, but what about this streaming approach? It should be working fine, it is just normal valid web approach.