The GitHub Actions job "Scalafmt" on pekko-grpc.git/max-message-len has failed. Run started by GitHub user pjfanning (triggered by pjfanning).
Head commit for run: 35c163258817cba48cb1fc3d2e7719994f23de4f / PJ Fanning <[email protected]> Address review findings on max inbound message size Motivation: Review of the max inbound message size work found that the central protection did not actually run, that the client setting was ignored on the default backend, and that several supporting details (per-request config parsing, a dropped reader cache, unvalidated settings) regressed behaviour or performance. Modification: - Codec.uncompress(compressedBitSet, bytes, max) now delegates to uncompress(bytes, max) so Gzip's streaming, size-bounded decoder is actually reached. Previously the base implementation fell through to the unbounded overload and checked the size only after decompressing in full, so the gzip bomb guard never ran and the bounded decoder was dead code. - Gzip's bounded decoder accumulates into a Long and clamps its initial buffer, so a limit near Int.MaxValue cannot be passed by an overflowing counter and a non-positive limit reports a gRPC status rather than IllegalArgumentException. - NettyClientUtils passes maxInboundMessageSize to NettyChannelBuilder, so the setting is no longer a silent no-op on the default backend. Applied before channelBuilderOverrides so explicit overrides win. - Restored the per-codec reader cache for the default limit; readers are built fresh only for a custom limit. newReader runs once per request. - GrpcFramingDecoderStage.ReadFrameHeader fails the stage explicitly instead of throwing out of parse, matching ReadFrame and avoiding a stack trace per rejected frame header. - The strict decoder reports a negative frame length as a gRPC status, matching the streaming path. - Renamed the new GrpcMarshalling.negotiated overload to negotiatedWithMaxSize. As an overload it broke inference of (reader, writer) lambda parameters at existing Scala call sites; the benchmark type ascriptions added to work around that are reverted. - Java handler template resolves GrpcServerSettings once in partial rather than per request, and takes GrpcServerSettings for parity with the Scala template, which now takes Option instead of a null sentinel. - Both settings classes require a positive maxInboundMessageSize, and fromConfig falls back on the default when the key is absent so hand-assembled Configs keep working. - Moved the pekko.grpc.server block out of the //#defaults snippet, which is rendered on the client configuration docs page, into its own marker. - Documented the limit for client and server, including that handlers generated before 2.0.0 use the default and cannot be reconfigured. Result: Oversized frames are rejected from the declared length before the payload is buffered, and gzip frames that inflate past the limit are rejected while decompressing rather than after. The limit applies on both client backends, misconfiguration fails fast, and the server hot path keeps its reader cache and per-call config resolution. Tests: - sbt "runtime/test" - 152 tests passed - sbt "runtime/mimaReportBinaryIssues" - passed - sbt "plugin-tester-scala/Test/compile" "plugin-tester-java/Test/compile" "interop-tests/Test/compile" "benchmarks/compile" - passed - sbt headerCreateAll scalafmtAll - applied - sbt "sbt-plugin / scripted" - Not run, left to CI - sbt +mimaReportBinaryIssues - Not run, single-version run passed, cross version left to CI References: Refs #818 Report URL: https://github.com/apache/pekko-grpc/actions/runs/32604345049 With regards, GitHub Actions via GitBox --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
