Skip to content

[SPARK-55930][SPARK-55931][CONNECT] Byte-aware gRPC metadata size checks and errorClassFallback#54728

Open
othon2000 wants to merge 3 commits intoapache:masterfrom
othon2000:master
Open

[SPARK-55930][SPARK-55931][CONNECT] Byte-aware gRPC metadata size checks and errorClassFallback#54728
othon2000 wants to merge 3 commits intoapache:masterfrom
othon2000:master

Conversation

@othon2000
Copy link

@othon2000 othon2000 commented Mar 10, 2026

What changes were proposed in this pull request?

This PR addresses two related issues in ErrorUtils around gRPC metadata size enforcement:

[SPARK-55930] Byte-aware size checks (SparkStringUtils)

  • Add sizeInBytes and abbreviateByBytes helpers to SparkStringUtils
  • Use sizeInBytes when checking messageParameters against the metadata size limit
  • Use abbreviateByBytes when truncating stackTrace to the limit

[SPARK-55931] Add errorClassFallback metadata key

When messageParameters JSON exceeds maxMetadataSize, surface the error class via a separate
errorClassFallback metadata key so proxy/interceptor systems can inspect the error class
without interfering with the existing FetchErrorDetails client/server flow.

[EXTRA]: Metadata byte count should take into account all metadata fields, instead of individual ones

Previous implementation checked individual metadata lengths against CONNECT_GRPC_MAX_METADATA_SIZE,
now we check all fields combined

Why are the changes needed?

Character-length-based checks undercount the actual byte size of gRPC metadata payloads when
multi-byte characters (e.g. CJK) are present, potentially causing MESSAGE_SIZE_LIMIT_EXCEEDED
errors at the transport layer: essentially an error when throwing an error, which is a debugging hell.

Additionally, when messageParameters are dropped due to size limits, there was no way for
observability or proxy layers to recover the error class from the metadata.

Does this PR introduce any user-facing change?

No.

How was this patch tested?

Added ErrorUtilsSuite covering buildStatusFromThrowable behavior, including:

  • Multi-byte character scenarios for byte-aware size checks
  • errorClassFallback propagation when messageParameters exceed the limit

Extended SparkStringUtils with unit tests for sizeInBytes and abbreviateByBytes.

Was this patch authored or co-authored using generative AI tooling?

Generated-by: Co-authored by Claude Sonnet 4.6

str
} else {
val budget = maxBytes - sizeInBytes(abbrevMarker)
val buf = StandardCharsets.UTF_8.encode(str)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we try to be a bit more careful with allocations. sizeInBytes(..) and this call both encode the string to bytes. At this point you have allocated 3 ByteBuffers. Can we bring it down to 1?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed one. To remove both, the implementation was quite convoluted. LMK if this is enough.

@othon2000 othon2000 marked this pull request as draft March 11, 2026 09:14
@othon2000
Copy link
Author

The implementation still contains a bug, where we are checking individual metadata fields against the limit but not their sum. Needs to be fixed.

othonc-db and others added 3 commits March 11, 2026 18:07
…ameters exceed size limit

When messageParameters JSON exceeds the maxMetadataSize limit, surface the
error class via a separate errorClassFallback metadata key to allow proxy
inspection without interfering with the FetchErrorDetails client/server flow.
Adds ErrorUtilsSuite to cover buildStatusFromThrowable behavior.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…elds

Replace character-length checks with UTF-8 byte size checks when enforcing
the gRPC metadata size limit. Multi-byte characters (e.g. CJK) can cause
length-based checks to undercount the actual byte size sent on the wire.

- Add `sizeInBytes` and `abbreviateByBytes` to `SparkStringUtils`
- Use `sizeInBytes` when checking `messageParameters` against the limit
- Use `abbreviateByBytes` when truncating `stackTrace` to the limit

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@othon2000 othon2000 marked this pull request as ready for review March 11, 2026 17:34
@othon2000
Copy link
Author

The implementation still contains a bug, where we are checking individual metadata fields against the limit but not their sum. Needs to be fixed.

This was fixed by 1fce674

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants