11 Commits

Author	SHA1	Message	Date
BilalG1	609579abab	feat(hexclave): PR 3 — native @hexclave/* source rename + delete dual-publish wiring (#1482)	2026-05-29 15:21:59 -07:00
Aman Ganapathy	c01c052ac9	[Refactor][Feat] Implement Plan Limits for Hard-and-Soft Item Caps (#1215) ... ### Suggested Review Areas Please see `plans.ts` and `seed.ts` to verify whether the item caps are where they should be. Outside of that, each commit should be atomic so stepping through the commits should give you an idea of how I implemented each limit. ### Discussion Something to discuss: when a user cancels team/growth we regrant free fine, but any extra-seats they had just keeps billing. So they end up paying ~$29/mo per extra-seat on top of free's 1 seat, which is strictly worse than just staying on team. This surfaced while manually testing this PR, we only enforce the add-on base requirement at purchase time, nothing cascades on cancel. Should we cascade cancel add ons? ### Context Now that we have a stable suite of products for stack-auth, we want to limit the items under each product a customer has access to based on their plan. So for example, a free plan user has a certain amount of emails they can send out each month, and so on. We try to implement limits in this PR. ### Summary of Changes Implemented hard limits for dashboard admins, analytics per-query timeouts, sent email monthly capacity, events, and session replays. Implemented a soft cap for auth users (where if there's a signup beyond the limit, we log it to sentry so we can manually choose to email that user/team). For auth users, we do not block new user sign ups once plan limit has been hit. We also don't degrade or impact the customer experience. It logs to sentry and it is up to us to take manual action to email the user to upgrade the plan. Also, implementation wise, we count all the users across all the projects for this team and compare it to their plan item limit, rather than debiting items like we do for other approaches. As a soft cap, this should be fine plus this is a better source of truth. For email capacity, we operate a monthly limit of emails. Once this is hit, no more emails can be sent until the next month/ a plan upgrade. These emails will be treated as a send error, so they can be manually resent once the capacity is reset. With respect to the `email-queue` state engine, they go from `SENDING`->`SERVER_ERROR`, hooking into the existing state engine flow, with an external error that shows it's because of the rate limit. This is cleaner than inventing a new state that is identical for all intents and purposes to `SERVER_ERROR`. We check in processSingleEmail since that maps to the sending state. For analytics query timeouts, the backend route accepts a timeout parameter with the request. The way we implement the timeout for each query is by taking the `min(request_timeout,plan_timeout)` and using that. This determines how long a query can run for. For analytics events, there are server-side events (like refresh token refreshes or sign up rule triggers) and client side events (like page views or clicks). When these events occur, they are written to the events table in clickhouse. We choose to implement a hard cap for the total events, not just server side or client side. Once the cap is hit, we stop storing the events and display a banner on the analytics page. A different banner renders when we are at >=80% of total plan capacity. For session replays, we stop creating new session replays when the limit is hit. Old replays can still have chunks appended to them. The source of truth here is the session replay table- a new replay corresponds to a new row in the table. We have similar banners as to the events. Dashboard admins should be 4 for both team and unlimited. #### Implementation Caveats For debiting items across these limits, we now use `tryDecreaseQuantity` at the beginning. This means we debit first if possible before conducting the action (like writing events to clickhouse). In practice, this means that if clickhouse fails, then the user is debited for something that doesn't happen. However trying to build a refund workaround would be very clunky, and also, clickhouse is reliable. For debits that are very small in the order of things (say, 200 items on a 100k plan), it doesn't mean much. For emails, we don't debit items if it's a retry. This prevents the user for being charged multiple times for effectively one email. ### UI Changes The only UI changes in this PR are having certain banners render in analytics when a customer is approaching/ is at their monthly limit of session replays or events. ### Out of Scope for this PR We do not have metered pricing yet, so events/session replays/ email use beyond the limits cannot be charged yet. This is why for this implementation, we rely on hard and soft caps. We do not implement payment per-transaction pricing yet. That is deferred to a followup PR. The UI for the onboarding call will be set up as part of the overall onboarding flow which doesn't exist yet, so it has been deferred. Since the UI for the dashboard home page and project/account settings is currently being reworked, finding a better spot for plan upgrades is not handled in this PR. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Session replays added as a monthly included entitlement; onboarding calls added to Team/Growth plans. Dashboard banners warn about analytics-event and session-replay limits. Projects page adds extra-seat flow and improved invitation error handling. * **Behavior Changes** * Monthly renewal semantics for emails-per-month and analytics-events; analytics query timeouts now respect plan limits and are clamped. Email sends, analytics events, and new session creation are blocked when quotas are exhausted. Growth plan seats set to 4. * **Tests** * E2E and unit tests added to verify quota enforcement and free-plan regranting. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Mantra <87142457+mantrakp04@users.noreply.github.com>	2026-05-04 18:25:13 -07:00
Konstantin Wohlwend	0a48aa5600	Increase email capacity during development to 100k/h	2026-04-10 15:53:55 -07:00
Aman Ganapathy	485fa9d623	[Refactor][Feat][Fix] Rework Email Section With New Sent Page, Better Drafts Page, and Settings Page (#1221) ... ### Context We didn't have an easy place for a user to see their domain statistics and track their sent emails, either overall or by draft. Additionally, there was scope creep with the sidebar, where we were supporting more pages. Our emails landing page was also rather confusing, especially toggling/ working with different email server types. So, we decide to add a "sent" page, to track email logs and email statistics, as well as let users temporarily override their sending limits if need be. Additionally, a user may want to see a particular email in more detail: what stage is it in? How did it proceed through time? How can I pause the sending of this email or change the scheduled time or edit the code? We allow for that to happen. ### Summary of Changes #### New Pages 1. **Sent Page:** A Domain Reputation card lets you track how many of your sent emails were bounced or marked as spam as well as how much capacity you have left. We also provide a temporary override, where you can use up to 4 times your capacity for a limited period of time. Additionally, we provide an email log that lets you see the recently sent emails. You can also toggle this view from a "list all emails" to "group by template/draft" which shows stats for each template/draft id (i.e a bar showing how many emails were sent, are pending, were marked as spam, were bounced etc, and the total number of emails sent with that template or draft). Clicking on an email in the list all view takes you to the "email-viewer" endpoint for that email (see below). Clicking on a template/draft in the group by view takes you to a page where you can see the statistics for that template/draft in more detail (the "send" stage view for that template/draft, as referenced below). 2. **Settings Page:** This is a new page we created because the old "emails" landing page wasn't doing its job. This page is to track all the email settings. Currently, we put in 2 sections. A "theme settings" card where users can see their active theme and click on a button to be navigated to the themes page. This is necessary as we remove themes from the sidebar. The other section is a card for email server and domain configuration - you can change your server type and adjust the settings or send a test email. It's cleaner and less noisy. 3. **Drafts Page**: There are a lot of changes here. On the landing page, we actually separate out the drafts into "active drafts" and "draft history" because drafts are meant to be fire-and-forget, not reusable. We also add the functionality to create a draft from a template. This was tricky to manage because templates rely on template variables which sent to the backend along with the code and injected during render time. We deal with this by having AI rewrite the template source code to remove any references to template variables and to make the draft standalone. The drafts page has been separated into a stepper-controlled multi stage process: draft->recipients->schedule->sent. Sent is a read only view that shows you the statistics of the emails sent using that draft, as mentioned earlier. You can also see the sent view of a historical draft. You can also bulk pause/cancel any unsent emails from the sent view of the drafts. 4. **Sidebar Updates**: The email sidebar now doesn't show "themes" or "emails" (the old landing page), but it does show "settings" and "sent", and the default landing page for emails is "sent". 5. **Email Viewer**: When you click on an individual email, you get navigated here. This has a timeline showing the progress of the email on the right, and some optional info for the user that's toggleable on the right bottom, while having either a preview of the email if it's sent or a way to edit it. You can also change the scheduledAt date of an email if it hasn't already been sent. #### Bug Fixes 1. **Search in `TeamMemberSearchTable`**: This was broken. Every time you tried to enter or remove a character, it would trigger skeleton loading that overlapped the search bar too, preventing you from adding/removing more. This was caused because the `useUser` hook eventually ended up calling a `use` hook, which throws a promise that triggers a suspense. This, coupled with the fact that the implementation of `TeamMemberSearchTable` involved a prop-drilling/ dependency inversion approach to passing down its toolbar to a base table component, meant the suspense would cover the toolbar too and couldn't be scoped to just the table. A refactor has gotten rid of the need for those base components while fixing tables in `payments/customers`, `teams/team_id`, and `payments/transactions` on top of the existing use in email drafts recipients stage. We also dedupped some code. 2. **Stale draft fetches on draft landing page**: `useEmailDrafts` uses an asyncCache to cache the fetched drafts. It is used on the drafts landing page to render the drafts. When a draft is sent, its `sentAt` is marked versus when it is still active, it is marked as null. The cache was stale and so navigating to the landing page after firing off a draft would errorneously represent that draft as still active and indeed, even allow you to edit it and fire it again. This violated the principle of drafts being fire and forget. This has been dealt with by adding functionality to refresh the draft cache upon firing off a draft. #### Other Changes 1. We bumped up the base time for the exponential send attempt retry backoff in `email-queue-step` to 20 seconds. The previous base was two seconds, and this effectively just made it wait until the next iteration of the `email-queue-step` cron job or at most an iteration that wasn't too far away. When an outage with our provider happens, it may take a while for it to be resolved, so a longer backoff is justified 2. We transitioned the themes page and the templates page to using the new components, though deeper UI refactors for them were out of scope for this ticket. 3. We implement a "temporarily increase capacity" button, that bumps up the throughput/ capacity limit fourfold for a user for a given period of time. It works like this: > Clicking the button sets a boost expiredat time. > When this time is set and still valid, the capacity rate is multiplied by 4. > When the button is clicked, trigger a loading spinner until the route finishes processing. > When the timer runs out, we reset the button back to its original state. > We dont need to wrap the onclick with runAsyncWithAlert because the component does that already. 4. We add a new default theme: a colorful theme with a lavender base. This was mainly done so we could have three times in a theme showcase in the settings page. ### UI Demos **Sent Page Demo:** https://github.com/user-attachments/assets/19294a90-bb65-4f00-9a97-111f6c08287f **Drafts Page Demo** https://github.com/user-attachments/assets/847609ef-d699-470c-a699-297bb9e17f04 **Settings Page Demo** https://github.com/user-attachments/assets/190a3829-036a-4f57-89c0-a873bef5a7ce **Email Viewer Page Demo** https://github.com/user-attachments/assets/3bc50159-4acb-4865-a4dd-830c84ee4235 --------- Co-authored-by: Konstantin Wohlwend <n2d4xc@gmail.com>	2026-03-11 12:01:36 -07:00
Aman Ganapathy	aeb5f77ebc	[Fix] Flaky Neon, Email Delivery, and Other Tests (#1235) ... ### Summary of Changes Just bumped up polling, removed unnecessary wait checks in tests that don't need them. Minor changes, not an exhaustive list of flaky test fixes Note that importing a function into a file B that was exported from a test file A causes vitest to see all the tests in test file A as being under file B. This messes up CI and makes it harder to track failing tests.	2026-03-10 14:02:41 -07:00
Armaan Jain	11b6b4210b	Emails redesign (#1076)	2026-02-16 14:57:17 -08:00
Konstantin Wohlwend	5d0f2a3775	Increase email wait	2026-02-13 10:53:21 -08:00
Konsti Wohlwend	e7e792d462	Email outbox backend (#1030)	2025-12-12 10:26:38 -08:00
BilalG1	5da45d8520	Email Drafts (#849) ... https://www.loom.com/share/cc379c5372244a169f3ae1d2cc91eae5?sid=ec5bc438-56d8-4cca-9bbc-6cf6c6d313ad <!-- ELLIPSIS_HIDDEN --> ---- > [!IMPORTANT] > Introduce email draft functionality with AI assistance, including creation, editing, and sending capabilities, and update APIs and UI components accordingly. > > - **Features**: > - Add email draft functionality: create, list, edit, preview, and send drafts. > - Integrate AI-assisted draft generation with `emailDraftAdapter` in `email-draft-adapter.ts`. > - Update `send-email` and `render-email` APIs to support drafts. > - **Backend**: > - Add `EmailDraft` model in `schema.prisma`. > - Implement draft CRUD operations in `email-drafts/route.tsx` and `email-drafts/[id]/route.tsx`. > - Update `render-email/route.tsx` and `send-email/route.tsx` to handle draft inputs. > - **Frontend**: > - Add email draft UI in `email-drafts/page-client.tsx` and `email-drafts/[draftId]/page-client.tsx`. > - Implement theme selection with `EmailThemeSelector` in `email-theme-selector.tsx`. > - Update sidebar navigation in `sidebar-layout.tsx` to include drafts. > - **Tests**: > - Add E2E tests for draft lifecycle and sending in `email-drafts.test.ts` and `send-email.test.ts`. > - **Misc**: > - Update `admin-interface.ts` and `server-interface.ts` to support draft operations. > - Add `XOR` type utility in `types.tsx` for exclusive option handling. > > <sup>This description was created by </sup>[<img alt="Ellipsis" src="https://img.shields.io/badge/Ellipsis-blue?color=175173">](https://www.ellipsis.dev?ref=stack-auth%2Fstack-auth&utm_source=github&utm_medium=referral)<sup> for c7ebb00ac5. You can [customize](https://app.ellipsis.dev/stack-auth/settings/summaries) this summary. It will automatically update as commits are pushed.</sup> ---- <!-- ELLIPSIS_HIDDEN --> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Email Drafts: create, list, edit, preview, theme-select, AI-assisted draft generation, send (marks draft as sent) and dashboard UI for drafting + recipient selection. * **Improvements** * Send/render APIs accept html, template, or draft inputs and an all-users option; per-recipient delivery/reporting, unified theme selector, expanded chat context for drafts, clearer schema validation errors, breadcrumb updates. * **Tests** * E2E coverage for draft lifecycle, draft-based send, all-users flow, and updated schema-validation snapshots. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Konsti Wohlwend <n2d4xc@gmail.com>	2025-09-10 22:57:18 +00:00
Konsti Wohlwend	40de0de4b9	Workflows (#873)	2025-09-03 01:22:08 -07:00
BilalG1	4899632ea4	Email sending sdk function, freestyle mock, small fixes (#813) ... <!-- Make sure you've read the CONTRIBUTING.md guidelines: https://github.com/stack-auth/stack-auth/blob/dev/CONTRIBUTING.md --> <!-- ELLIPSIS_HIDDEN --> ---- > [!IMPORTANT] > Enhances email sending API with template support, improved error handling, and new interfaces, while adding comprehensive tests and updating rendering logic. > > - **Behavior**: > - Adds support for sending emails using templates with variables and optional theming in `send-email/route.tsx`. > - Introduces per-user notification category checks before sending emails. > - Adds optional unsubscribe link in email themes. > - **Error Handling**: > - Refines error handling in `send-email/route.tsx` for missing content, non-existent user IDs, and shared email server configurations. > - Uses `KnownErrors` for specific error cases. > - **API Changes**: > - Adds new interfaces and methods for email sending in `server-interface.ts` and `admin-interface.ts`. > - Removes deprecated email sending methods from admin interfaces. > - **Testing**: > - Adds e2e tests in `email.test.ts` for various email sending scenarios, including HTML content, templates, and error cases. > - **Misc**: > - Updates email rendering logic in `email-rendering.tsx` to handle new template and theme options. > - Simplifies import statements and cleans up code structure across multiple files. > > <sup>This description was created by </sup>[<img alt="Ellipsis" src="https://img.shields.io/badge/Ellipsis-blue?color=175173">](https://www.ellipsis.dev?ref=stack-auth%2Fstack-auth&utm_source=github&utm_medium=referral)<sup> for 1d5a056699. You can [customize](https://app.ellipsis.dev/stack-auth/settings/summaries) this summary. It will automatically update as commits are pushed.</sup> ---- <!-- ELLIPSIS_HIDDEN --> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Enhanced email sending to support both raw HTML and template-based emails with variables and optional theming. * Added per-user notification category checks before sending emails. * Email themes now support an optional unsubscribe link in the footer. * **Improvements** * Updated email rendering to pass the unsubscribe link as a prop to themes. * Refined error handling for email sending. * Improved flexibility of email sending options and result reporting. * **API Changes** * Introduced new interfaces and methods for sending emails on the server side, including detailed result reporting. * Removed deprecated admin-side email sending methods and interfaces. * Added new types for email sending options and results. * **Bug Fixes** * Fixed navigation and property naming inconsistencies in dashboard email template editing and sending flows. * **Chores** * Simplified import statements and cleaned up internal code structure. * Updated Docker environment for freestyle mock service to use Bun runtime and adjusted port mappings. * **Tests** * Added comprehensive tests covering email sending scenarios, including error handling and multi-user support. * Updated existing tests to reflect refined email subjects, template rendering, and unsubscribe link features. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Konsti Wohlwend <n2d4xc@gmail.com>	2025-08-01 18:40:28 -07:00