fix(cloud-tests): only fire GCP broad fallback when folder list was forbidden#2918
Merged
Merged
Conversation
…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>
|
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
|
🎉 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.
Summary
Addresses cubic's P2 on the already-merged PR #2916: the broad-query fallback I added was firing any time folder enumeration returned an empty list, including the perfectly normal case where an org legitimately has no folders. For multi-org tenants that meant the picker for an empty-folder org could surface folder-nested projects from OTHER orgs the OAuth user had IAM access to (since the broad query is not org-scoped).
What changed
Folder enumeration helpers now return
{ folderIds, forbidden }, whereforbidden = trueonly when GCP responded with HTTP 403 on thev3/folderscall. The caller fires the broad-query fallback only when enumeration returned zero ANDforbiddenis true — exactly Greg's production failure mode.v3/folders200 + empty list (no folders exist)v3/folders403 PERMISSION_DENIED (Greg)v3/foldersreturns folder idsImpact on customers
propperai-prod/propperai-demo.v3/foldersis forbidden — same tradeoff as PR fix(cloud-tests): unblock GCP picker when folder enumeration returns 403 #2916 acknowledged: broad fallback may include cross-org folder projects. Acceptable because picker is selection-based and the alternative is an empty picker.Tests
forbiddenbranch.Manual test plan
propperai-prod/propperai-demo(his 403 case is preserved)./ecs/comp-production-apilogs filtered forGCP folder enumeration was forbidden— should still appear for Greg's connection.GCP folder fallback for orglog should NOT appear for them).🤖 Generated with Claude Code
Summary by cubic
Fix GCP project detection so the broad
parent.type:folderquery only runs when folder enumeration is actually forbidden (HTTP 403). This prevents cross-org projects from appearing when an org simply has no folders.v3/foldersreturns 403; do not fall back on 200 + empty.listFoldersUnderOrgandlistChildFoldersnow return{ folderIds, forbidden }; caller checksfolderIds.length === 0 && forbidden.Written for commit 173b031. Summary will update on new commits. Review in cubic