Why
- gogcli refreshed access tokens from a stored refresh token but never wrote back
a rotated refresh token returned by Google.
- In multi-process CLI usage this can leave keyring state stale across invocations
and eventually cause invalid_grant when the old token is retired.
What
- add persistingTokenSource wrapper in internal/googleapi/client.go
- wrap oauth2.Config TokenSource in tokenSourceForAccountScopes
- persist rotated refresh token back into secrets store when it changes
- keep persistence failures non-fatal (warn, return token)
- add unit tests for rotate/no-rotate/persist-failure paths
Tests
- go test ./internal/googleapi
When a Keep-specific service account file (keep-sa-*.json) exists,
tokenSourceForServiceAccountScopes falls back to it for all API calls,
not just Keep. This causes 401 errors on Calendar, Gmail, Drive, and
other services that should use OAuth.
Only use keep-sa and legacy Keep SA files when serviceLabel is "keep",
allowing other services to fall through to OAuth authentication.
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
* feat(drive): include shortcutDetails in drive get fields
Add shortcutDetails to the Drive Get API fields to enable resolving
shortcut target file IDs and MIME types.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix(googleapi): replace Client.Timeout with transport-level ResponseHeaderTimeout
The global http.Client.Timeout (30s) applied to the entire request
lifecycle, causing large Drive file downloads (videos, backups, etc.)
to time out. Replace it with http.Transport.ResponseHeaderTimeout
which only limits the time waiting for the server to begin responding.
Once response headers arrive and the body starts streaming, there is
no hard cap — large transfers complete naturally.
- Set ResponseHeaderTimeout=30s on the base transport
- Remove http.Client.Timeout from the API client
- Keep a dedicated tokenExchangeTimeout=30s for OAuth2 token refreshes
- Add tests verifying the new transport configuration
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
