Conversation
Customers with an org→folder→project hierarchy (a common SOC2-friendly layout) reported that their production projects never appeared in our GCP connection picker. Two bugs combined to cause it: 1. detectProjectsForOrg filtered with `parent.id:<orgId>`, which GCP's v1/projects API interprets as "immediate org children only". A project whose immediate parent is a folder under the org never matches, even if the user has full IAM access to it. 2. Both detectProjects and detectProjectsForOrg called the v1/projects list endpoint with pageSize=50 and never followed nextPageToken. For accounts with many sandboxes / Gemini default projects / etc., the first 50 results consumed the whole page and the production projects on later pages were silently dropped. Fix: - New `listProjectsPaginated(token, filter)` helper that follows nextPageToken until exhaustion, uses pageSize=200, and stops at a 1000-project safety cap. On a mid-pagination error it returns what it has so far — matches the prior "best-effort" picker posture and prevents a single transient 5xx from blanking the dropdown. - detectProjectsForOrg now issues two parallel paginated calls: one for direct org children (existing behavior) and one for any folder-nested project the caller has access to (`parent.type:folder`). Results merged + deduped. GCP's v1 list API has no "descendants-of-org" query, so the user's IAM scope is the effective filter for the folder-nested arm. - detectProjects refactored to use the same paginator. Direct list is paginated; org-scoped fallback is paginated. Backward compatibility: customers whose projects all live directly under an org see no behavior change (the folder-nested call returns 0 for them). Existing connections aren't touched — detection only runs at connect/re-auth. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…picker Switches `detectProjectsForOrg` from `Promise.all` → `Promise.allSettled` so a transient failure on the new folder-nested arm (e.g., GCP rejects the `parent.type:folder`-alone filter, DNS blip, transient 5xx during pagination) cannot blank the entire picker. The direct arm matches the prior production code path, so as long as it succeeds we are guaranteed to be no worse than today's prod even if the folder arm fails outright. Two new tests lock in the isolation: - direct arm succeeds, folder arm throws → returns direct results - folder arm succeeds, direct arm throws → returns folder results Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…rget org Addresses cubic P2 on PR #2899: the previous folder arm filter (`parent.type:folder` alone) would have returned projects from ANY org the caller had access to, violating the `detectProjectsForOrg` contract for multi-org users. The folder arm now recursively enumerates folders under the target org via `v2/folders?parent=organizations/<orgId>` (and recursively under each child folder), then queries each discovered folder with `parent.type:folder AND parent.id:<folderId>` — the paired filter shape GCP explicitly documents for by-parent project queries and which triggers their alternate consistent index. Behaviors preserved: - Promise.allSettled isolation so a failure on either arm cannot blank the picker. - Per-folder query failures are isolated (one bad folder doesn't kill the rest). - Safety cap of 500 folders to bound API usage. New tests: - Greg's exact scenario: only this org's folder gets queried. - Recursive sub-folder traversal (org → folder → sub-folder → projects). - Dedupe across arms. - Folder arm failure → direct arm still works. - Direct arm failure → folder arm still works. - Per-folder failure isolation. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Addresses cubic P2 on PR #2899: the previous `Promise.all` over every folder ID fires N simultaneous requests to cloudresourcemanager. For tenants with many folders, that can trip GCP's per-user read-quota, and because `listProjectsPaginated` returns the projects-collected-so- far on a non-OK response (including 429 Too Many Requests), a throttled folder query LOOKS like an empty folder — silently truncating the picker with no visible error. The fix bounds concurrent in-flight folder queries to 5 via a small inlined `mapWithConcurrency` helper. GCP's read quota (~600 req/min/user on cloudresourcemanager) is well above this, so the cap stays comfortably below throttling thresholds even for very deep folder hierarchies. Test added that builds a 20-folder tenant, holds the per-folder project queries open, and verifies: - peak in-flight count never exceeds 5 - all 20 folder queries eventually run (cap doesn't truncate work) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…pagination fix(cloud-tests): show folder-nested GCP projects in connection picker
|
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.61.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 so folder‑nested projects appear in the connection picker, and adds full pagination to avoid truncating results. Improves reliability with org‑scoped folder traversal and a small concurrency cap to prevent throttling.
Bug Fixes
v1/projectsusingnextPageToken(page size 200, 1000‑project safety cap); return partial results on mid‑page errors.v2/foldersfor that org and querying each folder withparent.type:folder AND parent.id:<folderId>; results merged and deduped with direct org children.Promise.allSettledso one arm (direct or folder) failing doesn’t blank results; per‑folder query failures are contained.Bug Fixes
gcp-security.service.spec.tsto cover pagination across multiple pages, org‑scoped folder traversal (including nested folders), deduping, failure isolation, concurrency capping, and safety limits.Written for commit dd253d0. Summary will update on new commits. Review in cubic