feat(bitbucket): add Code Reviewer support#4291
Conversation
| DROP INDEX "UQ_cloud_agent_code_reviews_repo_pr_sha";--> statement-breakpoint | ||
| ALTER TABLE "cloud_agent_code_reviews" ADD COLUMN "platform_repository_id" text;--> statement-breakpoint | ||
| ALTER TABLE "cloud_agent_code_reviews" ADD COLUMN "platform_workspace_id" text;--> statement-breakpoint | ||
| CREATE UNIQUE INDEX "UQ_cloud_agent_code_reviews_user_identity" ON "cloud_agent_code_reviews" USING btree ("owned_by_user_id","platform","platform_integration_id","platform_repository_id","pr_number","head_sha") WHERE "cloud_agent_code_reviews"."owned_by_user_id" is not null;--> statement-breakpoint |
There was a problem hiding this comment.
WARNING: New uniqueness is inactive until the backfill runs
platform_repository_id is still NULL for every existing row when these indexes are created, and Postgres unique indexes treat NULL values as distinct. Because line 1 drops the old repo/PR/head uniqueness first, a rolling deploy can insert duplicate reviews until the UPDATE at lines 7-13 populates this column. Populate/backfill the new identity before replacing the old uniqueness constraint.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
| "store_id": "342a86d9e3a94da698e82d0c6e2a36f0", | ||
| "secret_name": "BITBUCKET_OAUTH_CREDENTIAL_ACTIVE_KEY_ID_PROD", | ||
| }, | ||
| ], |
There was a problem hiding this comment.
WARNING: BITBUCKET_OAUTH_CREDENTIAL_ACTIVE_KEY_ID is still required at runtime
BitbucketWorkspaceAccessTokenAuthorizationService.decrypt() still reads env.BITBUCKET_OAUTH_CREDENTIAL_ACTIVE_KEY_ID to unwrap stored workspace tokens. Removing the binding here, and again under env.dev, leaves that env unset in deployed workers, so Bitbucket code-review lookups will fall back to secret_missing / temporarily_unavailable. Keep the binding or add an equivalent vars entry before shipping this config change.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
Code Review SummaryStatus: 1 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
Fix these issues in Kilo Cloud Files Reviewed (3 files)
Previous Review Summaries (4 snapshots, latest commit a01f56b)Current summary above is authoritative. Previous snapshots are kept for context only. Previous review (commit a01f56b)Status: 2 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
Fix these issues in Kilo Cloud Files Reviewed (3 files)
Previous review (commit a3e5861)Status: 2 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
Fix these issues in Kilo Cloud Files Reviewed (4 files)
Previous review (commit f642092)Status: No Issues Found | Recommendation: Merge Files Reviewed (1 files)
Previous review (commit 15e3d51)Status: 2 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
Fix these issues in Kilo Cloud Files Reviewed (123 files)
Reviewed by gpt-5.4-20260305 · Input: 125.3K · Output: 9.9K · Cached: 793.3K Review guidance: REVIEW.md from base branch |
| WHERE "platform_repository_id" IS NULL; | ||
| --> statement-breakpoint | ||
| DROP INDEX "UQ_cloud_agent_code_reviews_repo_pr_sha";--> statement-breakpoint | ||
| CREATE UNIQUE INDEX "UQ_cloud_agent_code_reviews_user_identity" ON "cloud_agent_code_reviews" USING btree ("owned_by_user_id","platform","platform_integration_id","platform_repository_id","pr_number","head_sha") WHERE "cloud_agent_code_reviews"."owned_by_user_id" is not null;--> statement-breakpoint |
There was a problem hiding this comment.
WARNING: These unique indexes still lock a populated table during deploy
The UPDATE immediately above backfills existing rows, so cloud_agent_code_reviews is already populated when these indexes are built. Creating them without CONCURRENTLY will block concurrent writes for the duration of the index build, which is the table-locking migration pattern we try to avoid on live tables.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
| return undefined; | ||
| } | ||
|
|
||
| if (url.protocol !== 'https:') return undefined; |
There was a problem hiding this comment.
WARNING: SSH clone URLs stop getting legacy GitLab or Bitbucket env setup
parseSessionMetadata() still accepts legacy gitUrl strings verbatim, including SSH forms like git@gitlab.com:group/repo.git. With the new https: gate here, platform-less legacy sessions now fall back to effectivePlatform === undefined, so the GitLab or Bitbucket env vars stop being injected even though the old substring fallback handled those stored clone URLs.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
| if (url.hostname !== 'bitbucket.org' || url.port || url.search || url.hash) return null; | ||
| if (url.protocol === 'https:') { | ||
| if (url.username || url.password) return null; | ||
| } else if (url.protocol === 'ssh:') { |
There was a problem hiding this comment.
WARNING: parseCanonicalBitbucketCloneUrl() no longer enforces the canonical HTTPS clone-URL contract
This helper also backs Bitbucket code-review admission in router/schemas.ts, so accepting ssh://git@bitbucket.org/... here now lets new review sessions through with non-canonical clone URLs. The rest of the repo still treats SSH Bitbucket clone URLs as invalid canonical identities, so this creates a mismatch between session admission and downstream URL validation.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
Summary
Verification
N/A
Visual Changes
N/A
Reviewer Notes
Review focus: Bitbucket webhook lifecycle, command guard allowlist, and integration disconnect cleanup.