Conversation
…dden Customer Propper hit a real failure that PR #2899's folder enumeration could not handle. Verified in production CloudWatch logs: WARN [GCPSecurityService] Failed to list child folders of organizations/43356919874: { "error": { "code": 403, "message": "The caller does not have permission", "status": "PERMISSION_DENIED" } } LOG [GCPSecurityService] GCP detectProjectsForOrg(43356919874): 13 direct + 0 folder-nested → 13 unique Two coordinated changes: 1. Switch `cloudresourcemanager.googleapis.com/v2/folders` → `cloudresourcemanager.googleapis.com/v3/folders`. v2 is deprecated and was observed returning 403 PERMISSION_DENIED for OAuth grants that legitimately had org-level folder roles (roles/owner + roles/resourcemanager.folderAdmin). v3 is the current API and accepts the same `parent`/`pageSize`/`pageToken` query params, so the swap is purely defensive — response shape is identical. 2. Add a broad-query fallback in `listProjectsInOrgFolderTree`. When folder enumeration returns zero folder IDs (whether due to 403, 404, no folders existing, or anything else), retry with a broader `lifecycleState:ACTIVE AND parent.type:folder` query. That returns every folder-nested project the OAuth user can `projects.get`, which solves Greg's case without depending on the folders endpoint succeeding. Multi-org tradeoff: in a multi-org tenant the fallback path may include folder-nested projects from other orgs the user has access to. This is acceptable because: - the picker is selection-based — the user chooses what to monitor, - the alternative is a silently empty picker like Greg saw, - the user already authorized those projects via their IAM grant. When v3/folders works as expected, the precise per-folder query is preferred and the fallback never fires — verified by a new test that locks in this behavior. Tests: - 2 new regression tests on `gcp-security.service.spec.ts`: - customer-Propper scenario: v3/folders empty → broad fallback fires → folder-nested projects appear. - healthy multi-org scenario: v3/folders succeeds → precise scoping preserved, broad fallback does not fire. - All 15 GCP detection tests pass; full cloud-security suite (269 tests) passes; one pre-existing TLS env failure is unrelated. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…on-fallback fix(cloud-tests): unblock GCP picker when folder enumeration returns 403
|
The latest updates on your projects. Learn more about Vercel for GitHub.
2 Skipped Deployments
|
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
1 issue found across 2 files
Confidence score: 3/5
- There is a concrete regression risk in
apps/api/src/cloud-security/providers/gcp-security.service.ts: the empty-folder fallback now expands scope to all accessible folder projects, which can misattribute projects across organizations. - Given the 6/10 severity with high confidence (8/10) and clear user-facing impact on org-specific project detection, this carries some merge risk rather than being a minor housekeeping issue.
- Pay close attention to
apps/api/src/cloud-security/providers/gcp-security.service.ts- empty-folder fallback logic may over-broaden project selection when an org has no folders.
Reply with feedback, questions, or to request a fix.
Fix all with cubic | Re-trigger cubic
…orbidden Cubic flagged PR #2916 (merged into main) with a P2 regression: the broad `parent.type:folder` fallback fired any time folder enumeration returned zero folders, including the case where an org legitimately has no folders at all. For multi-org tenants that meant the picker for an empty-folder org could surface folder-nested projects from OTHER orgs the OAuth user happened to have IAM access to (because the broad query is not org-scoped). Concrete cases: Case | Before (PR #2916) | After (this PR) ----------------------------------------------+-------------------+---------------- v3/folders returns 200 + empty (no folders) | Fallback fires | No fallback ✓ v3/folders returns 403 PERMISSION_DENIED | Fallback fires | Fallback fires ✓ v3/folders returns folder ids | No fallback | No fallback ✓ To distinguish the two cases, the folder-enumeration helpers now return `{ folderIds, forbidden }` where `forbidden` is true only when GCP responded with HTTP 403. The caller fires the broad query only when `folderIds.length === 0 && forbidden`. Customer Propper (Greg's case) is unaffected — their failure mode is "403 PERMISSION_DENIED" so the fallback still fires. New regression test locks in cubic's concern: when an org legitimately has no folders (200 OK + empty list), the broad fallback must NOT fire. The customer-Propper test was updated to return a real 403 response so it exercises the fallback path the way production does. Full cloud-security suite: 270/270 pass. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…rbidden fix(cloud-tests): only fire GCP broad fallback when folder list was forbidden
Contributor
|
@cubic-dev-ai review it |
Contributor
@tofikwest I have started the AI code review. It will take a few minutes to complete. |
Contributor
|
🎉 This PR is included in version 3.63.1 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is an automated pull request to release the candidate branch into production, which will trigger a deployment.
It was created by the [Production PR] action.
Summary by cubic
Fixes GCP project detection by switching folder listing to Cloud Resource Manager v3 and only using a broad folder-projects query when folder enumeration is forbidden (403). Folder-nested projects now appear for affected users while avoiding projects from other orgs when an org simply has no folders.
cloudresourcemanager.googleapis.com/v3/folders(v2 was deprecated and returned 403 for some OAuth grants).lifecycleState:ACTIVE AND parent.type:folderfires only on HTTP 403; does not run on 200 + empty results to preserve scoping in multi-org setups.Written for commit 0f2c990. Summary will update on new commits. Review in cubic