[BUG] SQS JSON responses over 8 KB use Transfer-Encoding: chunked (real SQS sends Content-Length); aws-sdk v2 on Node 26 hangs on them #6184

Service

SQS (JSON protocol, X-Amz-Target: AmazonSQS.*)

AWS API Action

ReceiveMessage, and any other SQS JSON response whose body is over 8,191 bytes (a large ListQueues or GetQueueAttributes, for example).

Expected behavior

Content-Length at any size, as real SQS sends. Measured against SQS in us-east-1 over HTTP/1.1 with the JSON protocol: a 25,624-byte ReceiveMessage came back with Content-Length: 25624, and an 802,258-byte one with Content-Length: 802258. Floci's own DynamoDB path already does this, because DynamoDbResponses.withCrc32 serializes the entity to byte[].

Actual behavior

SqsJsonHandler returns Response.ok(ObjectNode). Quarkus REST streams that entity through VertxOutputStream, which switches to Transfer-Encoding: chunked once the default 8,191-byte quarkus.rest.output-buffer-size overflows.

Measured on floci/floci:2.3.0@sha256:e0b292df4dc9559b7b1bf4f51bdda4bb8e269276236438cd03cae661260ea8a9:

Ten messages of about 2 KB each give a 23,654-byte chunked response. aws-sdk for JavaScript v2 (2.1693.0) then fails to resolve receiveMessage:

Why the client hangs: Node 26 made Readable.read() with no size return one buffered chunk at a time (nodejs/node#60441, semver-major). aws-sdk v2 calls read() once per 'readable' event, so when several chunks arrive in one socket read, 'end' never fires. aws-sdk v2 is archived and won't change, and Node treats the new behavior as intended. Others hit the same hang against other servers: balena-io/open-balena-api#2492, serverless/serverless#13971.

Chunked encoding is valid HTTP. But real SQS doesn't chunk these responses, and many Node services still receive through aws-sdk v2. On Node 26 they hang only against Floci, intermittently, and only once a batch crosses 8 KB.

Reproduction

docker run -d -p 4566:4566 floci/floci:2.3.0
aws --endpoint-url http://localhost:4566 --region us-east-1 sqs create-queue --queue-name big
Q=http://localhost:4566/000000000000/big
for i in $(seq 10); do aws --endpoint-url http://localhost:4566 --region us-east-1 sqs send-message --queue-url $Q --message-body "$(head -c 2000 /dev/zero | tr '\0' b)" >/dev/null; done
curl -sv -o /dev/null -X POST http://localhost:4566/ \
  -H 'Content-Type: application/x-amz-json-1.0' -H 'X-Amz-Target: AmazonSQS.ReceiveMessage' \
  -H 'Authorization: AWS4-HMAC-SHA256 Credential=test/20261021/us-east-1/sqs/aws4_request, SignedHeaders=host, Signature=0' \
  --data "{\"QueueUrl\":\"$Q\",\"MaxNumberOfMessages\":10,\"VisibilityTimeout\":0}" 2>&1 | grep -i '^< \(transfer-encoding\|content-length\)'
# < transfer-encoding: chunked

On Node 26 with aws-sdk@2:

const AWS = require('aws-sdk')
const sqs = new AWS.SQS({ endpoint: 'http://localhost:4566', region: 'us-east-1', credentials: { accessKeyId: 'test', secretAccessKey: 'test' } })
;(async () => {
  let hung = 0
  for (let i = 0; i < 30; i++) {
    const r = await Promise.race([
      sqs.receiveMessage({ QueueUrl: 'http://localhost:4566/000000000000/big', MaxNumberOfMessages: 10, VisibilityTimeout: 0 }).promise(),
      new Promise((res) => setTimeout(() => res('HANG'), 5000))
    ])
    if (r === 'HANG') hung++
  }
  console.log(`${hung}/30 hung`) // about half on Node 26, 0 on Node 24
  process.exit(0)
})()

Suggested fix

Serialize SQS JSON responses to byte[] at the AwsJsonController boundary, as DynamoDbResponses already does for DynamoDB. That gives Content-Length at any size. Raising quarkus.rest.output-buffer-size would only move the threshold, and the setting is fixed at build time.

Environment

• Floci version / image tag: 2.3.0, sha256:e0b292df4dc9559b7b1bf4f51bdda4bb8e269276236438cd03cae661260ea8a9 (SqsJsonHandler has not changed on main since)
• Java SDK version (if applicable): n/a. Clients: aws-sdk for JavaScript 2.1693.0 on Node 26.10.0, plus Node 24.21.0 and @aws-sdk/client-sqs v3 for comparison
• How you're running Floci: Docker (Docker Desktop on macOS arm64)