[qt/qt/qtgrpc]: Summary of bulk changes made

Git repository change summary for qt/qt/qtgrpc
Pushed by mirror-service into branch '6.12'.
Changed from ac51eb877fe5c41c049166a85af5e2d86943d8e1 to 8a34bffc289362eb0c8f28e0b78bd96ba96b7681
Acknowledgement was received that this change introduces only existing code that has been pushed to another public open source repository.

This change contains the following new commits:

Git commit 2cedde7ab6d6e4855171a89e9d5e1dd191b9c070 by Dennis Oberst on 18/08/2026 at 14:34..
QGrpcHttp2Channel: add reconnect backoff and connect timeout

QtGrpc reconnected immediately after every connection failure, with no
delay between attempts. A flapping or malicious server could therefore
drive the client into an unbounded, tight reconnect loop, exhausting
file descriptors, CPU, and network bandwidth (availability / DoS).

Rate-limit reconnection attempts with exponential backoff and jitter,
and bound how long a single attempt may hang before it is aborted.
Defaults match the gRPC specification: 1 s initial, 120 s maximum, 20 s
connect timeout. The backoff resets once the server acknowledges the
connection via the HTTP/2 SETTINGS frame.

QT_GRPC_INITIAL_RECONNECT_BACKOFF_MS,
QT_GRPC_MAXIMUM_RECONNECT_BACKOFF_MS, and QT_GRPC_CONNECT_TIMEOUT_MS
configure the three values. This is the manual backport announced in the
original change: only the environment variables come back, the
QGrpcChannelOptions setters stay in dev.

Conflicts resolved for 6.12:

* Dropped the public API access aswell as the tst_qgrpcchanneloptions
  coverage for them. The environment variables are the only
  configuration source here.
* Updated the documentation to only mention the env-vars.
* Reworked the end2end test to be driven through the environment
  variables.

[ChangeLog][QtGrpc][QGrpcHttp2Channel] The channel no longer reconnects
immediately after a connection failure. It now applies exponential
backoff with jitter, starting at 1 s and capped at 120 s, and aborts a
single connection attempt that hangs for more than 20 s. The
environment variables QT_GRPC_INITIAL_RECONNECT_BACKOFF_MS,
QT_GRPC_MAXIMUM_RECONNECT_BACKOFF_MS, and QT_GRPC_CONNECT_TIMEOUT_MS
override the three defaults.

Fixes: QTBUG-147829
Pick-to: 6.11 6.8
Change-Id: I9f7c6daa8305c69e2b3065abe139ee3ca746286c
Reviewed-by: Ivan Solovev <[email protected]>
Reviewed-by: Mate Barany <[email protected]>
(cherry picked from commit 9301338272f5d90dd7955e8ed7ebd2d2cfd01dd7)
https://invent.kde.org/qt/qt/qtgrpc/-/commit/2cedde7ab6d6e4855171a89e9d5e1dd191b9c070

Git commit c471993420bf8c41607cbda8fa8cadb0d51ade35 by Dennis Oberst on 18/08/2026 at 14:34..
QGrpcHttp2Channel: add a configurable maximum metadata size

QtGrpc placed no limit on the metadata received from a server, so a
misbehaving or malicious peer could send unbounded response headers and
exhaust client memory (availability / DoS).

Bound an incoming header block to 16 KiB (matching gRPC). The limit is
advertised as the HTTP/2 SETTINGS_MAX_HEADER_LIST_SIZE parameter and
enforced by QHttp2Connection as the block is received, so an oversized
block is rejected before it is fully buffered. It is floored at 4 KiB so
the mandatory protocol headers are never rejected, and is clamped to the
32-bit transport maximum.

The environment variable QT_GRPC_MAXIMUM_METADATA_SIZE overrides the
default. It is sampled once at channel construction to avoid acquiring
qEnvironmentVariable's global lock on a hot path.

This is the manual backport announced in the original change: only the
default advertisement and the environment variable come back, the
QGrpcChannelOptions setter stays in dev.

Conflicts resolved for 6.12:

* Dropped the public API access. The environment variable is the only
  configuration source here.
* QHttp2Configuration::setMaxHeaderListSize() is dev-only API in
  QtNetwork, so the limit is written through QHttp2ConfigurationPrivate.
* Updated the documentation to only mention the env-vars.
* Reworked the end2end test to be driven through the environment
  variables.

[ChangeLog][QtGrpc][QGrpcHttp2Channel] The channel now rejects metadata
larger than 16 KiB, matching the gRPC specification. The environment
variable QT_GRPC_MAXIMUM_METADATA_SIZE overrides the limit.

Task-number: QTBUG-147564
Fixes: QTBUG-147563
Pick-to: 6.11
Change-Id: I515230205da1bdf0886d76799649dd007619091f
Reviewed-by: Ivan Solovev <[email protected]>
(cherry picked from commit 3a67dac037f6cc16d6e4c059a188c1a6607b8f8e)
https://invent.kde.org/qt/qt/qtgrpc/-/commit/c471993420bf8c41607cbda8fa8cadb0d51ade35

Git commit 8a34bffc289362eb0c8f28e0b78bd96ba96b7681 by Dennis Oberst on 18/08/2026 at 14:35..
QGrpcHttp2Channel: warn when the outgoing message queue keeps growing

The channel queues outgoing messages without a size limit. An
application that writes faster than the network transmits them grows
the queue without bound and eventually exhausts client memory, with no
diagnostic pointing at the cause.

Track the bytes resident in the outgoing queue and warn when they
exceed 16 MiB, doubling the threshold after each report (32, 64 MiB,
...). A steady large upload thus warns once, while a runaway queue
leaves an escalating trail instead of per-write spam. Messages already
dequeued for transmission do not count, so a single large message in
transmission does not trip the warning.

Conflicts resolved for 6.12:

- The member block gained m_inFlightUserWrite in dev, from the
  messageWritten() change that is not picked here. Kept only
  m_queuedBytes and m_nextQueueWarnBytes.

Pick-to: 6.11 6.8
Task-number: QTBUG-148066
Change-Id: Iba15be8d80aae185ae2ea4d791a308d1b5af2836
Reviewed-by: Ivan Solovev <[email protected]>
(cherry picked from commit 842ecea3f52788aad545529069ff52c048486e92)
https://invent.kde.org/qt/qt/qtgrpc/-/commit/8a34bffc289362eb0c8f28e0b78bd96ba96b7681