Skip to content

fix(gmail): add x-goog-user-project header to helpers bypassing executor.rs - #939

Open
mittalpk wants to merge 1 commit into
googleworkspace:mainfrom
mittalpk:fix/gmail-inline-actions-quota-project-header
Open

fix(gmail): add x-goog-user-project header to helpers bypassing executor.rs#939
mittalpk wants to merge 1 commit into
googleworkspace:mainfrom
mittalpk:fix/gmail-inline-actions-quota-project-header

Conversation

@mittalpk

Copy link
Copy Markdown

Fixes #843.

fetch_message_metadata, fetch_send_as_identities, and fetch_attachment_data in crates/google-workspace-cli/src/helpers/gmail/mod.rs all call gmail.googleapis.com directly and only set .bearer_auth(token), so an ADC caller with no explicit quota project gets a 403 accessNotConfigured. executor.rs already handles this correctly via auth::get_quota_project() for standard resource commands; this applies the same pattern to the three Gmail helpers that bypass it.

This is a superset of the issue title: fetch_message_metadata is shared by +read, +forward, and +reply, and I found the identical bug in fetch_send_as_identities (used by From-header resolution) and fetch_attachment_data (original-attachment forwarding) in the same file, which the issue's own suggested fix called out as in scope ("and other helper functions that bypass executor.rs"). Other .bearer_auth-only call sites exist in calendar.rs, events/*.rs, workflows.rs, gmail/watch.rs, and gmail/triage.rs, but those hit different Google APIs (Calendar, Pub/Sub, Workspace Events) with potentially different quota-project requirements, so I left them out of this PR.

Verified cargo test (709 passing) and cargo clippy -- -D warnings clean on the changed file; there's one pre-existing clippy failure in helpers/script.rs unrelated to this change that reproduces on unmodified main too.

…tor.rs

fetch_message_metadata, fetch_send_as_identities, and fetch_attachment_data
all call gmail.googleapis.com directly with .bearer_auth(token) only, so ADC
callers with no explicit quota project get a 403 accessNotConfigured. Standard
resource commands avoid this because executor.rs already adds the header via
auth::get_quota_project(). Apply the same header conditionally in all three
helpers, which affects +read, +forward, +reply, send-as resolution, and
original-attachment forwarding.

Fixes googleworkspace#843
@changeset-bot

changeset-bot Bot commented Sep 13, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: d515881

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
@googleworkspace/cli Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@googleworkspace-bot googleworkspace-bot added the area: core Core CLI parsing, commands, error handling, utilities label Sep 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: core Core CLI parsing, commands, error handling, utilities

Projects

None yet

Development

Successfully merging this pull request may close these issues.

gmail +read returns 403 quota-project error when authenticated with default scopes

2 participants