Conversation
fix(trust): keep portal branding after save
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
Contributor
There was a problem hiding this comment.
1 issue found across 8 files
Confidence score: 3/5
- There is a concrete user-facing regression in
apps/app/src/app/(app)/[orgId]/trust/portal-settings/components/BrandSettings.tsx: rejecting empty values prevents persistingnull, so users can no longer clear the brand color. - Given the issue’s medium severity (6/10) and high confidence (8/10), this introduces meaningful behavior risk in settings management, so this is not quite in low-risk merge territory.
- Pay close attention to
apps/app/src/app/(app)/[orgId]/trust/portal-settings/components/BrandSettings.tsx- save validation currently blocks empty input needed to clear brand color.
Reply with feedback, questions, or to request a fix.
Fix all with cubic | Re-trigger cubic
…olor fix(app): allow clearing brand color and remove background check label
…coverage
Adds the building blocks for the manual-steps fallback shipped in the
next two commits, plus broadens the pattern matcher and actionable-
prefix list so more findings exercise the existing auto-repair paths
instead of bailing out:
1. New `AiRemediationService.generateManualSteps(...)`: takes the
finding, the failed plan, and the concrete failure reason, and
returns real customer-facing manual instructions via Sonnet (kept
on the cheap model since this only fires on failure paths and is
plain natural language). Hard fallback to the adapter remediation
text if the AI call itself throws, so the customer never sees a
raw error.
2. `looksLikeValidationError` now matches `MissingParameter`,
"must contain the parameter", "missing parameter",
"parameter is required", "must specify" — covers the EC2-style
error wording that the previous regex missed.
3. `ACTIONABLE_PREFIXES` adds `Authorize`, `Revoke`, `Allow`, `Deny`,
`Disable`, `Detach`, `Add`, `Remove`, `Register`, `Deregister`,
`Tag`, `Untag`. Security-group / IAM-style fix plans now produce
meaningful `willChange` diffs instead of `{}` `{}`.
4. Exports `FindingContext` so it can be reused by the orchestration
service (next commit) when invoking the new fallback path.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Customers were seeing raw "Fix could not be applied — <cryptic error>" when the AI's refined plan failed pre-execution validation or AWS rejected a step the executor couldn't auto-repair. The fix swaps every throw inside executeRemediation for a graceful fallback that returns real, AI-generated manual instructions in the existing `canAutoFix:false` response shape — so the frontend renders them with the guided-steps UI it already supports. Concrete changes inside the AWS executeRemediation flow: - Hoist `findingCtx` once at the top of the function so the refineFixPlan call, the per-step repair callback, and the new fallback path all see the same context. - Read-step validation failures → fall back to manual instead of throwing. (Read steps rarely fail; skipping repair here keeps the flow simple.) - "Refined plan has no fix steps" → fall back to manual instead of throwing. There's nothing to repair. - Refined-plan fix-step validation failures → NEW: attempt one AI repair pass on the offending steps (`repairInvalidSteps` parses the step indices from the validator errors and calls `refineStepFromError` per step), then re-validate. If still invalid, fall back to manual. Closes the gap where the executor's own AI step-repair never got a chance because the plan never reached execution. - Executor returned an unrecoverable error → fall back to manual, except for permission errors which still flow through the existing catch block (parseAwsPermissionError already has a polished fixScript payload — don't shadow it). GCP and Azure remediation services have the same throw-on-validation patterns and would benefit from the same treatment; left for a follow-up PR per the original scope. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The API change in the previous commit returns
`{ guidedOnly: true, guidedSteps, error }` when auto-fix gives up. This
commit threads that response shape through the trigger-task progress
metadata and the Remediation dialog so customers actually see the
manual steps instead of a raw error.
- `classifyExecuteResult` recognizes the new shape and emits a
`{ type: 'manual', reason, guidedSteps }` classification. Defensive
parsing strips non-string entries and ignores `guidedOnly` without
real steps. Permission errors keep their existing precedence.
- `remediateSingle` trigger task carries a new `phase: 'manual'` plus
`guidedSteps` in its progress payload.
- `RemediationDialog` reacts to the new phase by switching its
preview state into the existing guided-only rendering (same UI used
for plans where the AI declared `canAutoFix: false` upfront).
- The two batch-fix paths (single-account + integrations) treat the
manual classification as `failed` with the AI-generated reason — the
batch UI doesn't render per-finding guided steps, but the
user-facing message is now meaningful instead of cryptic. The
per-finding manual steps remain available via the single-fix dialog.
8 new tests on `execute-result.test.ts` (10 total) cover the manual
classification, the precedence rules, and the defensive parsing.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…allback fix(cloud-tests): graceful manual-step fallback so auto-remediate never shows raw errors
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.0 🎉 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
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
Adds a manual-steps fallback for cloud security auto-remediation so users always get clear instructions when a fix can’t be applied. Also fixes trust portal branding persistence (color and favicon), allows clearing brand color, and removes the exemption label in Background Checks.
New Features
Bug Fixes
TrustPortalBrandingSettings; normalize hex (#RRGGBB, uppercase); allow clearing the color to reset default; refresh vianext/navigation.UpdateTrustFaviconupdates preview, supports remove, and refreshes on success.Field/FieldLabelfrom@trycompai/design-systemandControllerfromreact-hook-form.Written for commit 35af953. Summary will update on new commits. Review in cubic