fix(dev): infinite get-session calls

[icecrasher321]

Summary

Get session at workspace level and pass it to components.

Type of Change

• Bug fix

Testing

Manually

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
docs	Ready	Preview	Comment	Aug 21, 2025 2:28am
sim	Ready	Preview	Comment	Aug 21, 2025 2:28am

[greptile-apps]

Greptile Summary

This PR addresses infinite session calls during hot module reloading (HMR) in development by implementing two key changes:

1. Singleton Better Auth Client Pattern: The auth client now uses a development-only singleton pattern that stores the client instance on globalThis to prevent multiple client instances from being created during HMR cycles. The getOrCreateClient() function checks for an existing client in development mode and reuses it, only creating new instances when necessary.

2. Centralized Session Management: Session fetching has been moved from individual components to the workspace layout level. A new WorkspaceSessionContext provides session data to all child components through React context, eliminating redundant useSession() calls throughout the component tree.

The changes affect multiple components across the workspace, including the sidebar, control bar, settings modals, and various management components. All components now use useWorkspaceSession() instead of directly calling useSession(), accessing user data through the centralized context. This architectural shift maintains identical functionality while significantly improving development performance by ensuring only one session fetch occurs per workspace load.

The implementation follows React best practices by lifting session state up to avoid prop drilling while providing controlled access to authentication data. The singleton pattern is conditionally applied only in development environments, ensuring production behavior remains unchanged.

Confidence score: 3/5

• This PR addresses a legitimate development issue but introduces type safety concerns with multiple any assertions
• Score reflects the use of type assertions to bypass TypeScript restrictions and potential runtime issues if globalThis behavior differs across environments
• Pay close attention to auth-client.ts for the type assertions and workspace/layout.tsx for the session context implementation

Context used:

Context - Avoid using type assertions to 'any' in TypeScript. Instead, ensure proper type definitions are used to maintain type safety. (link)

_{10 files reviewed, 2 comments}

_{Edit Code Review Bot Settings | Greptile}

[greptile-apps]

Greptile Summary

This review covers only the changes made since the last review (commit d46d2c2), not the entire PR.

The most recent changes focus on cleaning up the authentication implementation by addressing the type assertion issue identified in the previous review. The key change is the removal of the image field from the SessionUser interface and user object construction in the workspace layout. This eliminates the problematic type assertion to any that was previously used to access the image property from the session data.

Additionally, minor improvements were made to the login form by adding explicit type annotations to the error handling callback in the email sign-in function. The onError callback now has proper TypeScript types for the error context, improving type safety and developer experience.

These changes complement the existing singleton Better Auth client implementation and workspace-level session management that were addressed in the previous review, creating a more robust and type-safe authentication system.

Confidence score: 5/5

• This PR is safe to merge with minimal risk as it removes problematic code and improves type safety
• Score reflects the elimination of type assertions to any and addition of proper TypeScript typing
• No files require special attention as the changes are straightforward type safety improvements

Context used:

Context - Avoid using type assertions to 'any' in TypeScript. Instead, ensure proper type definitions are used to maintain type safety. (link)

_{4 files reviewed, no comments}

_{Edit Code Review Bot Settings | Greptile}