Repository navigation
Commit b771120
fix(github): the hourly token refresh keeps the account name the binding wrote, so the ETag cache stays on (#651)
`cacheInstallationToken` took the account as an OPTIONAL parameter and bound
`account?.login ?? ""` into an `ON CONFLICT … DO UPDATE SET account_login =
excluded.account_login`. Two of its three callers supply an account —
`authorizeInstallation` and `bindMemberOrgInstallations`, both of which have
just verified who owns the installation. The third, `installationTokenResult`,
is the token refresh and supplies nothing.
A GitHub installation token lives one hour, so every binding row fell through
to that refresh at least hourly and blanked its own `account_login` — and on
EVERY call when `KEY_ENCRYPTION_KEY` is unset, because the freshness branch
additionally requires the stored ciphertext.
`githubAuthContext` (github-cache.ts:121-127) names a read's authority by
matching that column against the repo owner. `''` matches no owner, so it
returned `null` — the module's documented fail-closed value — and both
`readGithubCache` and its write sibling short-circuit on a falsy context. So
from the first refresh onward, permanently, no authenticated GitHub read was
conditionally cached: deploy-watch.ts:243, hosted-repo.ts:155/:205,
github-issues.ts:154/:180, github-prs.ts:280/:340. deploy-watch's cron polls
per repo per tick, which is direct exposure to GitHub's primary rate limit.
`GET /v1/github/installations` also returned blank org names.
Fixed at the writer, not the reader: the UPDATE clause includes the account
columns only when the caller passed an account, so the refresh has no opinion
about a column it cannot know. The INSERT still writes '' into the NOT NULL
columns and is unreachable from the refresh path, which returns `no-binding`
before minting when the row is absent.
Verified NOT affected, as the issue claims: `resolveGithubAccess` matches the
owner against the LIVE App installation list, and the cross-tenant IDOR guard
keys on the binding row's existence, not on `account_login`. Repo resolution
and private-repo isolation were never at risk.
Already-blanked rows are NOT self-healing on ordinary sign-in — the issue's
guess was wrong. `bindMemberOrgInstallations` is called from exactly one place,
routes/auth.ts:153, inside the `state.linkUid` branch, which is the "Connect
GitHub" LINK flow and not the sign-in path. Rather than add a backfill
migration, `resolveGithubAccess` now hands the refresh the account it already
holds from the live App list — free, since that list was fetched anyway — so a
blanked row is corrected by the next authenticated read. Minting still requires
the verified binding row; nothing about authority changed.
Pinned with three tests over `realSchemaD1` (the migrations applied to real
in-memory SQLite, foreign keys ON): the refresh preserves the login, a binding
writer still corrects it, and `resolveGithubAccess` repairs a row already
blanked. The first fails against the old unconditional SET.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>1 parent 2f86fab commit b771120
2 files changed
Lines changed: 120 additions & 9 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
1 | 1 | | |
2 | | - | |
| 2 | + | |
| 3 | + | |
3 | 4 | | |
4 | 5 | | |
5 | 6 | | |
| |||
247 | 248 | | |
248 | 249 | | |
249 | 250 | | |
| 251 | + | |
| 252 | + | |
| 253 | + | |
| 254 | + | |
| 255 | + | |
| 256 | + | |
| 257 | + | |
| 258 | + | |
| 259 | + | |
| 260 | + | |
| 261 | + | |
| 262 | + | |
| 263 | + | |
| 264 | + | |
| 265 | + | |
| 266 | + | |
| 267 | + | |
| 268 | + | |
| 269 | + | |
| 270 | + | |
| 271 | + | |
| 272 | + | |
| 273 | + | |
| 274 | + | |
| 275 | + | |
| 276 | + | |
| 277 | + | |
| 278 | + | |
| 279 | + | |
| 280 | + | |
| 281 | + | |
| 282 | + | |
| 283 | + | |
| 284 | + | |
| 285 | + | |
| 286 | + | |
| 287 | + | |
| 288 | + | |
| 289 | + | |
| 290 | + | |
| 291 | + | |
| 292 | + | |
| 293 | + | |
| 294 | + | |
| 295 | + | |
| 296 | + | |
| 297 | + | |
| 298 | + | |
| 299 | + | |
| 300 | + | |
| 301 | + | |
| 302 | + | |
| 303 | + | |
| 304 | + | |
| 305 | + | |
| 306 | + | |
| 307 | + | |
| 308 | + | |
| 309 | + | |
| 310 | + | |
| 311 | + | |
| 312 | + | |
| 313 | + | |
| 314 | + | |
| 315 | + | |
| 316 | + | |
| 317 | + | |
| 318 | + | |
| 319 | + | |
| 320 | + | |
| 321 | + | |
| 322 | + | |
| 323 | + | |
| 324 | + | |
| 325 | + | |
| 326 | + | |
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
151 | 151 | | |
152 | 152 | | |
153 | 153 | | |
| 154 | + | |
| 155 | + | |
| 156 | + | |
| 157 | + | |
| 158 | + | |
| 159 | + | |
154 | 160 | | |
155 | 161 | | |
156 | 162 | | |
| |||
176 | 182 | | |
177 | 183 | | |
178 | 184 | | |
179 | | - | |
| 185 | + | |
180 | 186 | | |
181 | 187 | | |
182 | 188 | | |
183 | | - | |
| 189 | + | |
| 190 | + | |
| 191 | + | |
| 192 | + | |
| 193 | + | |
| 194 | + | |
| 195 | + | |
| 196 | + | |
| 197 | + | |
| 198 | + | |
| 199 | + | |
| 200 | + | |
| 201 | + | |
| 202 | + | |
| 203 | + | |
| 204 | + | |
| 205 | + | |
| 206 | + | |
| 207 | + | |
| 208 | + | |
| 209 | + | |
| 210 | + | |
| 211 | + | |
184 | 212 | | |
185 | 213 | | |
186 | 214 | | |
| |||
192 | 220 | | |
193 | 221 | | |
194 | 222 | | |
| 223 | + | |
| 224 | + | |
| 225 | + | |
195 | 226 | | |
196 | 227 | | |
197 | 228 | | |
198 | 229 | | |
199 | | - | |
200 | | - | |
201 | | - | |
| 230 | + | |
202 | 231 | | |
203 | 232 | | |
204 | 233 | | |
| |||
383 | 412 | | |
384 | 413 | | |
385 | 414 | | |
386 | | - | |
387 | | - | |
388 | | - | |
| 415 | + | |
| 416 | + | |
| 417 | + | |
| 418 | + | |
| 419 | + | |
| 420 | + | |
| 421 | + | |
| 422 | + | |
389 | 423 | | |
390 | 424 | | |
391 | 425 | | |
| |||
0 commit comments