Skip to content

Insanely slow response times when using ADC auth and not regular auth #7345

Open

Description

@AndyClausen

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

A screenshot that you have tested with "Try this API".

time gsutil ls gs://gcp-public-data-arco-era5/ar/model-level-1h-0p25deg.zarr-v1/hybrid (example bucket) gives this:

real    0m1.896s
user    0m0.383s
sys     0m0.152s

Link to the code that reproduces this issue. A link to a public Github Repository or gist with a minimal reproduction.

https://github.com/AndyClausen/storage-performance-issue-example

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

Scenario 1 - requests hang forever:

  1. run gcloud auth revoke to make sure you're not logged into gcloud normally
  2. run gcloud auth application-default login and log in
  3. run bun i to install deps
  4. run bun start

Scenario 2 - everything works:

  1. run gcloud auth login and log in
  2. run gcloud auth application-default login and log in
  3. run bun i to install deps
  4. run bun start

Scenario 3 - requests hang for about 15 seconds:

  1. run gcloud auth login using an account that is set up to require re-authentication after a period of time
  2. wait for said amount of time
  3. run gcloud auth application-default login and log in
  4. run bun i to install deps
  5. run bun start

A clear and concise description of what the bug is, and what you expected to happen.

There's something going on with authentication. If I log in to gcloud with ADC only, requests hang seemingly forever. If I log in with regular auth and ADC, everything works fine and it uses ADC. If I log in with regular auth and wait for the token to expire, and log in with ADC freshly, it hangs for around 15 seconds.

It's a bit difficult to reproduce the last scenario, but the first two should be simple.

The reproduction repo uses getFiles as an example, and the example bucket is just some public bucket I found from a quick google search.

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

I would expect the library to ignore regular auth and just use ADC, but it seems like it's checking regular auth credentials first for some reason, even though it ends up just using ADC. This is not an issue with gsutil, so I don't know why it is with this library.

Activity

  1. github-actions commented on Sep 5, 2025

    @github-actions
    Contributor

    Issue was opened with an invalid reproduction link. Please make sure the repository is a valid, publicly-accessible github repository, and make sure the url is complete (example: https://github.com/googleapis/google-cloud-node)

  2. AndyClausen commented on Sep 5, 2025

    @AndyClausen
    Author

    I just double-checked, and the repo is a valid, publicly-accessible and github repo, and the url is complete. I don't know why the bot thinks otherwise.

  3. github-actions commented on Sep 10, 2025

    @github-actions
    Contributor

    Issue was opened with an invalid reproduction link. Please make sure the repository is a valid, publicly-accessible github repository, and make sure the url is complete (example: https://github.com/googleapis/google-cloud-node)

  4. thiyaguk09 commented on Apr 16, 2026

    @thiyaguk09
    Contributor

    The issue stems from the credential discovery sequence in google-auth-library-nodejs. The library is getting stuck attempting to refresh expired user sessions or probing the Metadata Server before falling back to valid ADC.

    Key Findings:

    • Root Cause: The GoogleAuth waterfall logic is not "failing fast." It waits for network timeouts on expired gcloud auth login credentials rather than immediately using the local ADC file.
    • Impact: This causes significant hangs (15s+) for all Node.js client libraries (Storage, Pub/Sub, etc.) as they all depend on this core auth provider.

    This must be addressed in the auth library specifically, as service-level libraries simply await the provider's resolution.

  5. removed their assignment
    on Jun 3, 2026
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

    api: storageIssues related to the Cloud Storage API.library: storageIssues transferred from another repository

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions