You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
LoggingServiceV2Client loses automatic WriteLogEntries batching after the logging-api split #9658
@google-cloud/logging — comparing 11.2.1 and 12.0.0
A screenshot that you have tested with "Try this API".
Not applicable: this issue concerns client-side request batching in the generated Node.js SDK. API Explorer sends requests directly and cannot exercise the SDK's google-gax batching scheduler.
The linked reproduction uses mocked transport calls and exercises the actual generated client wrappers and google-gax scheduler. It requires no credentials or Google Cloud project and makes no real Google Cloud API calls.
No API Explorer test was performed.
Link to the code that reproduces this issue. A link to a public Github Repository or gist with a minimal reproduction.
A step-by-step description of how to reproduce the issue, based on the linked reproduction.
Requirements: Node.js 22 or newer and npm.
Clone the reproduction:
git clone https://github.com/jacekerd/google-logging-batching-repro.git
cd google-logging-batching-repro
Install the two locked dependency trees:
npm ci --prefix versions/v11 --ignore-scripts --no-audit --no-fund
npm ci --prefix versions/v12 --ignore-scripts --no-audit --no-fund
Inspect batching metadata and exercise compatible writes:
npm run check:v11
npm run check:v12
npm run behavior
npm test
Run the assertion that v12 should preserve v11 batching behavior:
npm run test:expect-v11
Observed results:
v11.2.1 has descriptors.batching.writeLogEntries; two compatible writes produce one mocked transport invocation containing both entries.
v12.0.0 has an empty descriptors.batching object; the same writes produce two separate mocked transport invocations.
npm test passes five tests documenting these observations.
npm run test:expect-v11 intentionally exits 1, with one failed parity assertion.
The reproduction uses real generated wrappers and google-gax scheduling, with the transport stubbed. No credentials or real Cloud API requests are required.
A clear and concise description of what the bug is, and what you expected to happen.
Automatic WriteLogEntries batching differs between @google-cloud/logging@11.2.1 and @google-cloud/logging@12.0.0.
In 11.2.1, LoggingServiceV2Client initializes descriptors.batching.writeLogEntries and combines compatible calls into one transport request.
In 12.0.0, LoggingServiceV2Client is re-exported from @google-cloud/logging-api@0.2.0. That generated implementation has an empty batching descriptor object and lacks the corresponding bundling defaults and batching descriptor selection.
Actual: two compatible calls produce two transport requests instead of one.
Explicit higher-level log.write([entry1, entry2]) remains supported. The issue concerns automatic coalescing across separate GAPIC calls.
These versions establish the behavioral difference; they do not identify the first affected intermediate release.
A clear and concise description WHY you expect this behavior, i.e., was it a recent change, there is documentation that points to this behavior, etc. **
@google-cloud/logging@11.2.1 automatically combines compatible WriteLogEntries calls. I expected this behavior to remain available after upgrading to 12.0.0.
The historical Node.js generation target explicitly supplied google/logging/v2/logging_gapic.yaml, which defines batching for WriteLogEntries. Investigation indicates that the logging-api onboarding omitted nodejs.bundle_config from librarian.yaml, causing the generated client to lose its batching descriptor, bundling defaults, and batching descriptor selection.
The reproduction demonstrates one mocked transport invocation for two compatible writes in v11, versus two invocations in v12. Restoring the missing configuration in memory restores batching with v12's existing google-gax runtime.
Then regenerate the Logging API client. This restores the WriteLogEntries batching descriptor, bundling defaults, and descriptor selection through the generation configuration.
The attached patch also includes a mocked regression test covering compatible requests being combined and requests with different discriminator values remaining separate.
I have not opened a PR. Does this approach match the intended generation workflow?
Activity
jacekerd commentedon Oct 19, 2026
upstream-batching.patch.txt
I also prepared a proposed fix locally.
In librarian.yaml, add the following to the Logging API library's nodejs configuration:
bundle_config: google/logging/v2/logging_gapic.yamlThen regenerate the Logging API client. This restores the WriteLogEntries batching descriptor, bundling defaults, and descriptor selection through the generation configuration.
The attached patch also includes a mocked regression test covering compatible requests being combined and requests with different discriminator values remaining separate.
I have not opened a PR. Does this approach match the intended generation workflow?