Conversation
* ## Mcp-typescript SDK Changes: * `CompAi.People.PeopleController_updateMember_v1()`: `response.status[409]` **Added** (Breaking⚠️ ) * empty commit to trigger [run-tests] workflow --------- Co-authored-by: speakeasybot <bot@speakeasyapi.dev> Co-authored-by: speakeasy-github[bot] <128539517+speakeasy-github[bot]@users.noreply.github.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}
…nied in oauth flow ## Problem The CodeQL integration incorrectly reports that GitHub Advanced Security (GHAS) is not enabled when using OAuth, even though GHAS is actually active on the repository. This forces customers to manually upload evidence as a workaround and causes confusion about automation support. ## Root cause The `isGhasEnabled` check in code-scanning.ts conflates two distinct failure modes. It returns false both when `advanced_security.status` is explicitly 'disabled' AND when the `security_and_analysis` block is absent from the API response. Over OAuth, GitHub only returns this block to repository admins due to permission constraints. The check treats a missing block (permission denied) the same as an explicitly disabled status (feature not enabled), returning the 'ghas-required' error in both cases. ## Fix Updated the logic to distinguish between the two scenarios. When `security_and_analysis` is absent, we now return 'permission-denied' instead of 'ghas-required'. This accurately reflects that we lack permission to read the setting rather than claiming GHAS is disabled. The check still returns 'ghas-required' only when status is positively 'disabled'. No changes to auth, RBAC, API schemas, or GitHub App integration paths. Behavior for genuinely-disabled repos and the GitHub App connection remains unchanged. ## Explicitly NOT touched - OAuth token validation or scoping - GitHub App integration or permissions - Repository admin checks or RBAC logic - API schema or response structure ## Verification ✅ Code path for explicitly disabled GHAS still returns 'ghas-required' ✅ Code path for missing security_and_analysis block now returns 'permission-denied' ✅ GitHub App path unaffected (receives full security_and_analysis block) ✅ No schema changes required
…ration-incorrectly-repor fix(github-integration): distinguish ghas disabled from permission denied in oauth flow
…held The task Automations card derived "Last ran" from the visible run list, which excludes runs held server-side as inconclusive. A scheduled check whose runs kept being held therefore showed a days-old "Last ran" while it was in fact running daily — customers read it as a dead schedule. The /runs endpoint now also returns lastAttempts: the newest run timestamp per (connection, check) INCLUDING held runs — timestamps only, held outcomes stay hidden. The card advances "Last ran" to the newest attempt when the check already has visible history; counts, status, and "Not run yet" for held-only checks are unchanged. Fixes CS-753
…eld-runs fix(app): keep task automation "Last ran" fresh when recent runs are held
…3448) * fix(people): make role picker modal-aware in invite members dialog ## Problem When inviting members and trying to select roles from the MultiRoleCombobox in the invite dialog, the role picker popover does not respond to clicks. Users cannot select any roles, blocking member invitations entirely. ## Root cause The role picker (MultiRoleCombobox) is a non-modal Popover rendered inside a modal Radix Dialog (InviteMembersModal). Without the `modal` prop, the Popover operates as a regular popover and its CommandItem.onSelect handlers do not fire when the parent is a modal. The earlier fix adding `pointerEvents:auto` CSS only masked the symptom at the DOM level but did not resolve the underlying modal stacking issue. Radix Popover respects the `modal` prop to coordinate focus and events with parent modals. ## Fix Pass `modal={true}` to the Popover component wrapping the role picker. The PopoverContent already spreads props to its Radix primitive, so the prop is honored without additional plumbing. ## Explicitly NOT touched No changes to RBAC permission logic, vendor dependencies, or data migration. This is a UI layer fix in the People feature. ## Verification ✅ Role picker CommandItems fire onSelect when clicked inside InviteMembersModal ✅ Users can select and confirm roles during member invitation ✅ Tested in Safari and Chrome (the customer's reported browsers) * fix(people): dedupe radix singletons so the role picker works in every browser packages/ui pinned @radix-ui/react-popover to 1.1.15, whose transitive react-dismissable-layer/react-focus-scope/react-focus-guards versions differ from react-dialog's, so bun installed and bundled two copies of each. These modules coordinate through module-level singletons, so the invite dialog and the role picker popover could not see each other's layers or focus scopes: - Safari: the dialog's focus trap yanked focus out of the popover the moment it autofocused its search input, and the non-modal popover dismissed itself on that outside focus. Chrome survived only because it focuses buttons on click, making the yank land on the popover trigger, which is exempt from dismissal. - Both browsers: Escape closed the popover AND the invite dialog (both layer copies considered themselves topmost), and typing to filter roles did nothing because focus never stayed in the search input. Bumping react-popover to ^1.1.19 aligns its transitive deps with react-dialog@1.1.19 so only one copy of each singleton module exists. The modal popover then traps focus in the search input, Escape closes only the popover, and role selection works in Chromium and WebKit (verified with a Playwright harness against the real installed tree). Also adds a module-identity regression test that fails if a future version bump reintroduces the duplicate copies.
…ti (#3444) ## Problem When using the Comp AI MCP server with API-key auth, the Trust Center *config* write endpoints all return a `400 Bad Request` with `Organization mismatch. You can only manage resources for your own organization.` — even when the correct `organizationId` is passed. **Affected endpoints:** * `update-overview` * `update-faqs` * `create-custom-link` **Working endpoints (same API key + org):** * `update-policy` * `publish-all-policies` * `upload-trust-document` **Steps to reproduce:** 1. Authenticate with API-key auth against the Comp AI MCP server 2. Call any of the affected endpoints with the correct `organizationId` 3. Observe `400` response: `Organization mismatch. You can only manage resources for your own organization.` **Expected behaviour:** Requests succeed, consistent with other endpoints using the same credentials. **Actual behaviour:** `400 Bad Request` — org-context check fails on Trust Center config endpoints only. **Hypothesis:** The org-context validation logic on the Trust Center config routes (`overview`, `FAQs`, `custom links`) appears to be checking a different org context than the one passed in the request — unlike the policy and document endpoints which resolve it correctly. **Customer impact:** Customer is currently managing overview, FAQs, and custom links manually via the dashboard as a workaround. **1** **Org ID:** `org_6a4fc9acd549402f180da8ce` --- ticket comments --- Unthread: Linked to Unthread ticket: > [Trust Center config write endpoints return "Organization mismatch" 400 error despite correct organizationId #11482](https://compai.unthread.io/dashboard/inbox/all/conversations/6e2d04c2-a9ba-46fc-bb25-5d8436851e71) [redacted-email]: This comment thread is synced to a corresponding [thread in Slack](https://comp-ai-workspace.slack.com/archives/C09CV8JCGKD/p1784271059974019). All replies are displayed in both locations. ## Fix [Bug] Trust Center config write endpoints return "Organization mismatch" 400 despite correct organizationId ## Verification ✅ added a regression test; suite green locally
Contributor
|
🎉 This PR is included in version 3.104.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
Deploys
@trycompai/mcp-serverv0.2.3 to production. Fixes OAuth code scanning GHAS false positives, keeps Automations “Last ran” accurate with held-run timestamps, makes the People role picker work in invite/edit dialogs, and unblocks Trust Center API-key writes in MCP by adding request bodies to OpenAPI (overview, FAQs, custom links).Dependencies
mcp-typescriptto 0.2.3 and regenerated SDK; OpenAPI adds HTTP 409 for member update; bumped versions/links to thev0.2.3bundle.@radix-ui/react-popoverto^1.1.19to align with@radix-ui/react-dialogand enable modal popovers.Migration
PeopleController_updateMember_v1(email already used or member in other orgs). Adjust client error handling and UI copy.Written for commit 2304d1f. Summary will update on new commits.