Conversation
[dev] [Marfuen] mariano/eng-198-error-trying-to-run-cloud-tests
Co-authored-by: chasprowebdev <chasgarciaprowebdev@gmail.com> Co-authored-by: Mariano Fuentes <marfuen98@gmail.com>
PR SummaryMedium Risk Overview Tightens a few related UX/behavior edges. The API now clears Improves error messaging for GCP Security Command Center. Adds explicit handling for SCC Legacy deprecation and for projects where the SCC API is not enabled (both in the API Also includes small correctness/maintenance tweaks: recursive “comment has content” detection, marks the Written by Cursor Bugbot for commit da6ab06. This will update automatically on new commits. Configure here. |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Co-authored-by: chasprowebdev <chasgarciaprowebdev@gmail.com> Co-authored-by: Mariano Fuentes <marfuen98@gmail.com>
| 'The Security Command Center API is not enabled for this project. ' + | ||
| 'Enable it in the GCP console: APIs & Services > Enable APIs > Security Command Center API.', | ||
| ); | ||
| } |
There was a problem hiding this comment.
Specific GCP error checks unreachable due to ordering
Medium Severity
The new checks for Security Command Center Legacy and Security Command Center API has not been used are placed after the existing PERMISSION_DENIED/403 check. GCP API error responses typically embed the HTTP status code and gRPC status in the response body JSON, so these errors will almost always contain "403" or "PERMISSION_DENIED", causing the generic handler to match first. The more specific and helpful error messages will never be shown to users. The companion file packages/integrations/src/gcp/src/index.ts doesn't have this issue because it has no 403 catch-all.
Additional Locations (1)
The `next` package was listed as a dependency in `packages/email` but was never imported or used anywhere in the package. It is not a peer dependency of any of the package's actual dependencies (react-email, resend, etc.). Removing it to avoid unnecessary dependency maintenance. Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Bumps the npm_and_yarn group with 1 update in the /packages/device-agent directory: [electron](https://github.com/electron/electron). Updates `electron` from 33.4.0 to 35.7.5 - [Release notes](https://github.com/electron/electron/releases) - [Commits](electron/electron@v33.4.0...v35.7.5) --- updated-dependencies: - dependency-name: electron dependency-version: 35.7.5 dependency-type: direct:development dependency-group: npm_and_yarn ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Mariano Fuentes <marfuen98@gmail.com>
| 'Security > Security Command Center > Settings.', | ||
| ); | ||
| } | ||
|
|
There was a problem hiding this comment.
Missing "API not enabled" error check in integration
Low Severity
The gcp-security.service.ts file adds both a "Security Command Center Legacy" and a "Security Command Center API has not been used" error check, but packages/integrations/src/gcp/src/index.ts only adds the "Legacy" check. Both services call the same GCP Security Command Center API endpoint and can encounter both errors. Users of the integration package will get a generic "Failed to fetch findings" message instead of the helpful guidance about enabling the API.
Additional Locations (1)
…2404) * fix(app): pass isPlatformAdmin value to FindingItem to make 'Ready for Review' enabled by client * fix(app): remove isAuditor and add canSetReadyForReview param to FindingItem * fix(app): remove isPlatformAdmin prop from FindingItem --------- Co-authored-by: chasprowebdev <chasgarciaprowebdev@gmail.com> Co-authored-by: Mariano Fuentes <marfuen98@gmail.com>
Ramp integration is no longer needed. This removes all Ramp-related code across the stack: manifest, API services/controllers, sync endpoints, frontend components (role mapping UI, sync provider), and scheduled sync. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Auto-clear employeeSyncProvider if the manifest no longer exists (covers orgs that had Ramp configured before removal) - Guard Image component against empty src when provider logo is missing Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Generic manifest check would break dynamic providers during transient registry gaps. Scope to explicit 'ramp' check instead. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Remove Ramp integration
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
There are 3 total unresolved issues (including 2 from previous reviews).
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
| data: { employeeSyncProvider: null }, | ||
| }); | ||
| return { provider: null }; | ||
| } |
There was a problem hiding this comment.
Ramp provider is forcibly unset on reads
Low Severity
getEmployeeSyncProvider always clears employeeSyncProvider when it equals 'ramp'. This mutates state during a read and wipes a valid provider selection if a sync-capable dynamic provider uses the ramp slug, causing the provider to reset to null unexpectedly.


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.