diff options
| author | Peter Stone <thepeterstone@gmail.com> | 2026-09-20 08:05:38 +0000 |
|---|---|---|
| committer | Peter Stone <thepeterstone@gmail.com> | 2026-09-20 08:05:38 +0000 |
| commit | 4c22de26ed3720411c2c2351f900dd4c1415b3f8 (patch) | |
| tree | 0d8b0d476b9d1b69f9401ca5bc1d679afa4f9dd1 /android/app/src/test/java/org/terst/doot/widget | |
| parent | 4d160762aeef531208f8cf6094a0e58a9e7d53ec (diff) | |
Fix Google Tasks: token refresh used a cancelled context
main.go builds the Tasks client with a short-lived init context and calls
cancel() the moment construction returns. dbTokenSource captured that context
and reused it for every subsequent token refresh, so the first refresh after
the startup access token aged out — roughly an hour in — failed with
"context canceled", and so did every one after it.
That is the whole reason Google Tasks has not been working: all four task
lists, the same error on every fetch, recovering only for an hour after each
restart. The message pointed at a transport problem, which is why it read as
flaky networking rather than a lifetime bug.
A token refresh is not logically part of whichever request happened to trigger
it, so it now gets its own background context with its own timeout. oauth2's
client is likewise built on context.Background(), since NewClient binds the
context it is given to the returned transport for its lifetime; per-call
contexts still come from the tasks service methods.
Regression test drives a refresh through a stub token endpoint with an
already-cancelled construction context, which fails on the old code with
exactly the production error. Also covers Google omitting refresh_token on a
refresh response, which would otherwise blank the stored one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
Diffstat (limited to 'android/app/src/test/java/org/terst/doot/widget')
0 files changed, 0 insertions, 0 deletions
