refactor(cloud-agent-next): migrate to git-token-service RPC#2747
refactor(cloud-agent-next): migrate to git-token-service RPC#2747
Conversation
Replace the in-worker GitHubTokenService and InstallationLookupService with calls to the shared git-token-service Worker via a GIT_TOKEN_SERVICE service binding, and drop the now-redundant token fetching in the web app routers. - Wire GIT_TOKEN_SERVICE binding in wrangler.jsonc; drop GITHUB_APP_ID, GITHUB_LITE_APP_ID, GITHUB_TOKEN_CACHE KV and HYPERDRIVE bindings. - Resolve GitHub tokens for repo + managed GitLab tokens through a new shared helper (src/services/git-token-service-client.ts) used from both session-prepare and async-preparation paths. - Persist gitlabTokenManaged in session metadata so the DO can refresh GitLab tokens on startExecutionV2 via refreshManagedGitLabToken. - Restore the 'No GitLab integration found' BAD_REQUEST at session prepare so the failure surfaces early instead of as an opaque git clone error. - Web routers (personal + org) no longer fetch GitHub/GitLab tokens for prepareSession/sendMessage — cloud-agent-next handles token resolution and refresh centrally.
![kilo-code-bot[bot]](https://avatars.githubusercontent.com/in/2193792?s=60&v=4){kind=small}
| githubToken, | ||
| gitToken, | ||
| }); | ||
| return await client.sendMessage(input); |
There was a problem hiding this comment.
WARNING: Existing GitLab sessions lose token refresh after rollout
gitlabTokenManaged is only written for sessions prepared under the new code path. Sessions that were already prepared before this deploy still rely on the web app to send a fresh gitToken on each sendMessage; after this change they fall back to the original prepare-time token in DO metadata, so long-lived sessions can start failing once that token rotates or expires.
| GITHUB_APP_PRIVATE_KEY: env.GITHUB_APP_PRIVATE_KEY, | ||
| GITHUB_LITE_APP_ID: env.GITHUB_LITE_APP_ID, | ||
| GITHUB_LITE_APP_PRIVATE_KEY: env.GITHUB_LITE_APP_PRIVATE_KEY, | ||
| const result = await env.GIT_TOKEN_SERVICE.getGitLabToken({ |
There was a problem hiding this comment.
WARNING: RPC exceptions still break the execution
This helper is documented as best-effort, but getGitLabToken() is awaited without a try/catch. If the service binding throws during a transient outage, startExecutionV2() falls into its outer error path and returns INTERNAL instead of continuing with the last stored token.
| orgId: metadata.orgId, | ||
| }); | ||
| if (result.success) { | ||
| return result.token; |
There was a problem hiding this comment.
WARNING: Successful refreshes are not persisted
When this returns a newer token, the DO metadata still keeps the original metadata.gitToken. A later refresh failure will therefore fall back to the stale prepare-time token, not the last known working token described in the comment.
Code Review SummaryStatus: 3 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
Other Observations (not in diff)No additional observations. Files Reviewed (11 files)
Reviewed by gpt-5.4-20260305 · 1,036,451 tokens |
1 participant
Summary
Replaces the in-worker
GitHubTokenServiceandInstallationLookupServiceincloud-agent-nextwith calls to the sharedgit-token-serviceWorker via a newGIT_TOKEN_SERVICEservice binding, and removes the now-redundant token pre-fetching in the web app tRPC routers.Architectural changes
cloud-agent-nextno longer talks to Postgres (Hyperdrive) or KV to resolve GitHub App installations / cache tokens. A singleGIT_TOKEN_SERVICE.getTokenForRepo/getToken/getGitLabTokenRPC replaces both services.services/cloud-agent-next/src/services/git-token-service-client.ts, used from both the synchronoussession-preparepath and theautoInitiateasync preparation path.gitlabTokenManagedflag is persisted inCloudAgentSessionmetadata. When set,startExecutionV2refreshes the GitLab token on every execution via a newrefreshManagedGitLabTokenhelper on the DO.cloud-agent-next-router.ts+organization-cloud-agent-next-router.ts) stop fetching GitHub/GitLab tokens forprepareSessionandsendMessage.cloud-agent-nexthandles token resolution and refresh centrally. TheNo GitLab integration found. Please connect your GitLab account first.BAD_REQUESTpreviously surfaced by the web app is now raised insidecloud-agent-nextat prepare time, preserving the UX.wrangler.jsonc: wires theGIT_TOKEN_SERVICEbinding (prod + dev) and dropsGITHUB_APP_ID,GITHUB_LITE_APP_ID, theGITHUB_TOKEN_CACHEKV namespace and theHYPERDRIVEbinding.Net change: −549/+286. The old KV namespace (
GITHUB_TOKEN_CACHE) and Hyperdrive config (HYPERDRIVE) in Cloudflare are now unbound; they can be decommissioned after rollout.Verification
GIT_TOKEN_SERVICEbinding being available in thecloud-agent-next+cloud-agent-next-devWorker environments; rollout should be coordinated withgit-token-servicedeployment. Suggested manual checks before/after deploy to staging:prepareSession(web) → DO initialises with a resolved installation token;/streamreceivesready.prepareSessionreturnsBAD_REQUEST: No GitLab integration found….sendMessageon a long-running GitLab-managed session after token rotation → the DO refreshes via RPC without the web app forwarding a token.Visual Changes
N/A
Reviewer Notes
git-token-servicemust exposeGitTokenRPCEntrypoint(withgetTokenForRepo,getToken,getGitLabToken) in both prod and dev before this worker is deployed.ab4d777d134a43248639044613ea29ef(prod) /33b5f1f1be064e919934bee83df4067c(dev) and Hyperdrive id624ec80650dd414199349f4e217ddb10are no longer referenced — follow up to delete if nothing else uses them.CloudAgentSession.refreshManagedGitLabTokenis best-effort: on RPC failure it logs a warning and returns the last-known token rather than failing the execution. Worth eyeballing whether that's the desired behaviour for all callers (startSessionandresumeSession).async-preparation.tsnow re-resolves the GitLab token even thoughsession-prepare.tsalready resolved it on theautoInitiatefast path — a small duplicate RPC, kept for simplicity (resolved values aren't plumbed throughPreparationInput).prepareSession; the error now comes fromcloud-agent-next. The message text is identical so UX should match.services/cloud-agent(V1) still uses its own token path; this refactor is scoped tocloud-agent-nextand the web routers that target it.