Replace custom server action guards with next-safe-action

[ben-fornefeld]

Replace custom server action guards with next-safe-action

Summary

This PR replaces our custom guard abstraction for server actions with the next-safe-action library, providing improved type safety, error handling, and client-side state management while reducing maintenance burden.

Motivation

Our current approach using custom HOF-based guards worked but required ongoing maintenance and didn't provide optimal client-side state handling. The next-safe-action library offers a more robust, well-maintained alternative with additional features:

• Chainable middleware pattern for composable action behaviors
• Built-in error handling and logging
• Consistent typed responses across all actions
• Client-side hooks for optimistic updates and loading states

Changes

Server-side

• Created a base action client with error handling and logging middleware
• Implemented authActionClient that extends the base client with auth checks
• Added .metadata() to all actions for improved observability
• Migrated all server actions from custom guard to next-safe-action pattern

Client-side

• Replaced startTransition and tanstack query mutation hooks with useAction hook
• Updated UI components to handle the standardized result schema

Other Issues fixed

• user & teams fetching now done on the server side
• network banner layouting

[linear]

E2B-1810 refactor server-actions to next-safe-action

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
web	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 17, 2025 2:35pm
web-juliett	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 17, 2025 2:35pm

[jakubno]

The name of PR is misguiding, it isn't only about server action guards, there are also changes unrelated to that. This makes it very hard to review

[ben-fornefeld]

The name of PR is misguiding, it isn't only about server action guards, there are also changes unrelated to that. This makes it very hard to review

fair, 90% is about the server action guards. the problem is more that the state management in the component had to be rewritten as soon as the action implementation changed. so it was big from the beginning