LoggingServiceV2Client loses automatic WriteLogEntries batching after the logging-api split · Issue #9658 · googleapis/google-cloud-node · GitHub
Skip to content

LoggingServiceV2Client loses automatic WriteLogEntries batching after the logging-api split #9658

Open

Description

@jacekerd

Please make sure you have searched for information in the following guides.

Library Name

@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.

https://github.com/jacekerd/google-logging-batching-repro

A step-by-step description of how to reproduce the issue, based on the linked reproduction.

Requirements: Node.js 22 or newer and npm.

  1. Clone the reproduction:

    git clone https://github.com/jacekerd/google-logging-batching-repro.git
    cd google-logging-batching-repro
  2. 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
  3. Inspect batching metadata and exercise compatible writes:

    npm run check:v11
    npm run check:v12
    npm run behavior
    npm test
  4. 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.

Expected: compatible WriteLogEntries calls retain automatic batching.

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.

Relevant references:

I'd expect the automatic GAPIC batching to be preserved across this migration.

Activity

  1. jacekerd commented on Oct 19, 2026

    @jacekerd
    Author

    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.yaml

    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?

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions