[comp] Production Deploy #1917
[comp] Production Deploy #1917
Conversation
* feat(auth): add Microsoft sign-in integration and update environment variables * chore: improve error handling for Microsoft sign-in --------- Co-authored-by: Tofik Hasanov <annexcies@gmail.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub. 2 Skipped Deployments
|
PR SummaryAdds org-wide Browserbase web automations (APIs, DB, scheduling, and UI), plus Microsoft SSO and zod v4 upgrade.
Written by Cursor Bugbot for commit d0b353c. This will update automatically on new commits. Configure here. |
|
|
Graphite Automations"Auto-assign PRs to Author" took an action on this PR • (12/12/25)1 reviewer was added to this PR based on Mariano Fuentes's automation. |
* feat(browserbase): add browser automation features and context management * refactor(api): add evaluation status and reason to browser automation runs * chore(dependencies): update package versions in bun.lock * chore(hooks): handle session management and cleanup in useBrowserExecution * chore(api): handle stagehand closure on navigation error * chore(test-browserbase): remove TestBrowserbasePage and TestBrowserbaseClient components * refactor(browser-connection): improve session management and cleanup on errors * chore(browserbase): implement context creation with pending state handling * refactor(browser-automations): simplify next scheduled run calculation * refactor(browserbase): increase maxSteps from 10 to 20 in execution * chore(browser-automations): implement browser automation configuration and management --------- Co-authored-by: Mariano Fuentes <marfuen98@gmail.com>
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
| return await this.browserbaseService.createSessionWithContext( | ||
| dto.contextId, | ||
| ); | ||
| } |
There was a problem hiding this comment.
Bug: Missing organization ownership check on session creation endpoint
The createSession endpoint accepts a contextId directly from the request body without verifying it belongs to the authenticated user's organization. The createSessionWithContext service method uses the provided contextId directly without any authorization check. Browser contexts store authenticated sessions (cookies, localStorage) for sites like GitHub and Jira. An authenticated user from one organization could potentially create a session using another organization's contextId and access their saved authentication tokens. While contextId values are UUIDs and not easily guessable, this violates defense-in-depth principles. The endpoint should look up the contextId using the authenticated user's organizationId rather than accepting it from client input.
Additional Locations (1)
| return (await this.browserbaseService.createBrowserAutomation( | ||
| dto, | ||
| )) as BrowserAutomationResponseDto; | ||
| } |
There was a problem hiding this comment.
Bug: Automation CRUD endpoints lack organization authorization checks
The createAutomation endpoint accepts a taskId from the request body without verifying the task belongs to the authenticated user's organization. The service directly creates the automation with the provided taskId. When the daily scheduled task runs (browserAutomationsSchedule), it executes all enabled automations using the linked task's organizationId to access that organization's browser context. An attacker could create automations linked to another organization's tasks, and when the scheduler runs at 5 AM UTC, the malicious automation executes with the victim's authenticated browser sessions. Similar authorization gaps exist in getAutomationsForTask, getAutomation, updateAutomation, and deleteAutomation endpoints.
Additional Locations (1)
* chore(db): add migration for organizationId and new browser automation tables
| } catch (error) { | ||
| if (!isPrismaUniqueConstraintError(error)) { | ||
| throw error; | ||
| } |
There was a problem hiding this comment.
Bug: Pending context record not cleaned up on API failure
In getOrCreateOrgContext, if the Browserbase API call (bb.contexts.create) fails after inserting a database record with PENDING_CONTEXT_ID, the pending record is never cleaned up. This leaves organizations stuck in a perpetual pending state where subsequent calls will either timeout after 10 seconds or fail silently.
Additionally, getOrgContext returns __PENDING__ as a valid context ID without checking for this state. This causes downstream code to attempt using an invalid context ID, leading to failures when creating browser sessions.
The organization would need manual database intervention to recover from this state.
Additional Locations (1)
| enabled: true, | ||
| trustedProviders: ['google', 'github', 'microsoft'], | ||
| }, | ||
| }, |
There was a problem hiding this comment.
Bug: Account linking config incorrectly nested under model mapping
The accountLinking configuration is nested inside the account model mapping object, which is only meant for specifying modelName. In better-auth, accountLinking is a root-level configuration option that enables automatic account linking for OAuth providers. The current nesting means the accountLinking settings will likely be ignored, preventing the new Microsoft SSO account linking feature from working as intended. Users signing in with Microsoft may not have their accounts linked to existing email-based accounts.
Additional Locations (1)
|
|
||
| const handleNeedsReauth = useCallback(() => { | ||
| context.startAuth(authUrl); | ||
| }, [context, authUrl]); |
There was a problem hiding this comment.
Bug: useCallback depends on entire context object causing re-renders
The handleNeedsReauth callback has context (the entire hook return object) as a dependency instead of just context.startAuth. Since the useBrowserContext hook returns a new object reference on every render, this causes handleNeedsReauth to be recreated on every render. This then causes useBrowserExecution's runAutomation to be recreated on every render since it depends on onNeedsReauth. The dependency should be context.startAuth instead of context.
* chore(browserbase): add ensureActivePage method for page management * refactor(browserbase): improve stagehand closure handling in service
| // Create session with live view | ||
| const { sessionId, liveViewUrl } = await this.createSessionWithContext( | ||
| context.contextId, | ||
| ); |
There was a problem hiding this comment.
Bug: Run record left in running status on session failure
The startAutomationWithLiveView method creates a browserAutomationRun record with status 'running' before calling createSessionWithContext. If session creation fails and throws an exception, the run record is left in 'running' status indefinitely because there's no try-catch to update it to 'failed'. This contrasts with runBrowserAutomation which properly wraps session creation in error handling and marks runs as failed on exceptions.
* refactor(hooks): ensure onComplete is always called after execution
* refactor(aws-security): simplify AWS credentials handling and improve logging
|
🎉 This PR is included in version 1.71.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
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.