Closed
Conversation
…en serveManager is set in dev (#3851)
…3857) ### TL;DR Improved inspector connection handling with better endpoint discovery and error handling. ### What changed? - Added a new `getInspectorClientEndpoint` function that attempts to discover the correct client endpoint URL by checking metadata - Fixed the KV key reference in `engine-data-provider.tsx` to use `KV_KEYS.INSPECTOR_TOKEN` instead of the entire `KV_KEYS` object - Enhanced the connection process in `inspector-root.tsx` to use the new endpoint discovery function - Added proper metadata schema validation using Zod - Improved error handling for inspector connections ### How to test? 1. Attempt to connect to an inspector URL in the UI 2. Verify that the connection works with both direct URLs and URLs that require endpoint discovery 3. Test with invalid URLs to ensure proper error handling 4. Verify that the inspector token is correctly retrieved from KV storage ### Why make this change? This change improves the reliability of connecting to inspector endpoints by implementing a discovery mechanism that can find the correct client endpoint URL. It handles various URL formats and validates the connection properly, making the inspector connection process more robust and user-friendly.
### TL;DR Added command history functionality to the actor console input. ### What changed? - Added state management for command history in `actor-console-input.tsx` using `useState` hooks - Implemented up/down arrow key navigation through previously executed commands - Added new props to the `ReplInput` component to handle history navigation - Added keyboard event handlers for ArrowUp and ArrowDown keys ### How to test? 1. Open the actor console 2. Enter and execute multiple commands 3. Press the up arrow key to cycle through previously executed commands (newest to oldest) 4. Press the down arrow key to navigate forward through the history 5. Verify that pressing down at the end of history clears the input ### Why make this change? This improves the developer experience when working with the actor console by allowing users to easily recall and reuse previously executed commands, similar to how terminal interfaces work. This saves time and reduces errors when users need to repeat or modify previous commands.
### TL;DR Fixed a bug in the guard connectable inspector by improving error handling when token or metadata is missing. ### What changed? - Reordered the destructured variables in the `useActorInspectorData` hook for better readability - Enhanced the error condition check to verify that both `token` and `metadata` exist before rendering content - Previously, the component only checked `isError` but now it also checks for the existence of required data ### How to test? 1. Navigate to a page with the actor inspector component 2. Test scenarios where token or metadata might be undefined: - Test with invalid actor IDs - Test with network failures - Test with partial data responses 3. Verify that the error handling works correctly and the component doesn't attempt to render with missing data ### Why make this change? This change prevents potential runtime errors that could occur when the component tries to use `token` or `metadata` that might be undefined. The previous implementation only checked for explicit errors but didn't account for missing data, which could lead to unexpected behavior or crashes.
# Temporarily Disable Pagination and Update Connection Dialogs ### TL;DR Temporarily disabled pagination in the engine data provider and updated connection dialogs with improved region selection and environment variable handling. ### What changed? - Temporarily disabled pagination in the engine data provider - Changed default mode from "serverfull" to "serverless" in connection dialogs - Fixed region selection to use region name instead of ID in Railway and manual connection frames - Added `RIVET_ENDPOINT` environment variable to Vercel template - Added a new "variables" step to the Vercel connection flow - Updated UI labels in the runner config toggle group (changed "Dedicated" to "Runners") - Added support for prefixless endpoint environment variables ### How to test? 1. Verify that pagination is disabled in the engine data provider 2. Check that connection dialogs default to "serverless" mode 3. Confirm region selection works correctly in Railway and manual connection frames 4. Test the Vercel connection flow with the new "variables" step 5. Verify environment variables are correctly displayed with both prefixed and prefixless options ### Why make this change? These changes improve the connection experience by defaulting to serverless mode, which is more appropriate for most users. The pagination disabling is a temporary fix for an issue that needs to be addressed later. The environment variable improvements ensure better compatibility with various deployment platforms, particularly Vercel, by providing both prefixed and prefixless options.
### TL;DR Fixed a typo in the `prefixlessEndpoint` parameter and improved the Actor Inspector UI with better loading states and version information. ### What changed? - Fixed a typo in the `EnvVariables` component, renaming `prefixlessEndpint` to `prefixlessEndpoint` - Added loading spinners to Actor Inspector tabs (Connections, Events, State) - Added version information display in the Actor General tab - Created a new `ActorRunner` component to display runner information - Improved error handling and UI feedback for outdated RivetKit versions - Exported the `Row` component from `runners-table.tsx` for reuse - Enhanced the Inspector connection status UI with better feedback - Added minimum version requirement check for RivetKit (2.0.35) ### How to test? 1. Verify the environment variables are correctly displayed in the Vercel connection form 2. Test the Actor Inspector with both up-to-date and outdated RivetKit versions 3. Check that loading states display correctly in the Actor Inspector tabs 4. Verify that version information appears in the Actor General tab 5. Confirm that runner information displays properly in the Actor Runner component ### Why make this change? These changes improve the user experience by providing better feedback during loading states and clearer error messages when using outdated versions of RivetKit. The typo fix ensures consistent naming throughout the codebase, and the addition of version information helps users understand compatibility requirements. The enhanced UI feedback makes it easier for users to understand the connection status of the Actor Inspector.
### TL;DR Swapped pagination functionality between actors and another endpoint. ### What changed? - Re-enabled pagination for actors by uncommenting the code that checks if the number of actors is less than `RECORDS_PER_PAGE` and returns the pagination cursor - Temporarily disabled pagination for another endpoint by commenting out the cursor return and adding a FIXME comment with the same attribution (@NathanFlurry) ### How to test? 1. Navigate to a page that displays actors 2. Verify that pagination works correctly when there are more actors than fit on a single page 3. Check that the other endpoint (which had pagination disabled) doesn't attempt to load additional pages ### Why make this change? It appears that pagination was temporarily disabled for actors but should now be re-enabled, while pagination for another endpoint needs to be temporarily disabled. This change ensures the correct pagination behavior for each endpoint.
### TL;DR Improved actor inspector reliability by updating query retry logic and fixing the inspector guard component. ### What changed? - Added retry configuration to actor metadata query options: - Set `retry: 0` to prevent automatic retries - Added `retryDelay: 5_000` to wait 5 seconds between retries - Set `refetchInterval` to periodically refresh data (5 seconds in one case, 1 second in another) - Moved query configuration from the component level to the query options - Fixed the `InspectorGuard` component to properly handle error states and data availability: - Now checks for missing data or errors before checking loading state - Shows the `OutdatedInspector` component when data is unavailable or there's an error ### How to test? 1. Open the actor inspector for any actor 2. Verify that the inspector loads correctly 3. Temporarily disconnect from the network and verify the inspector shows the outdated state 4. Reconnect and verify the inspector recovers properly ### Why make this change? This change improves the reliability of the actor inspector by ensuring proper error handling and implementing a consistent retry strategy. The updated logic ensures users see appropriate feedback when the inspector can't connect to an actor, and the periodic refetching helps maintain up-to-date information.
### TL;DR Added error reporting for runner configuration health checks using PostHog. ### What changed? - Extended the `queryMeta` interface to include a new `reportType` field - Added PostHog error reporting in the query cache's `onError` handler when a `reportType` is specified - Implemented the error reporting specifically for runner configuration health checks by setting `reportType: "runner-config-serverless-health-check"` in the connection check query ### How to test? 1. Trigger a failed runner configuration health check 2. Verify that PostHog captures an event with type "runner-config-health-check" containing the error details and query key ### Why make this change? This change improves error tracking for runner configuration health checks, allowing us to better understand and diagnose issues users encounter when setting up serverless runners. By capturing these errors in PostHog, we can analyze patterns and improve the configuration experience.
### TL;DR Enable authentication requirement for Plain chat widget. ### What changed? Added the `requireAuthentication: true` parameter to the Plain.init configuration in the frontend Vite cloud config file. ### How to test? 1. Load the application in cloud environment 2. Verify that the Plain chat widget requires authentication before allowing users to interact with it 3. Confirm that unauthenticated users cannot access the chat functionality ### Why make this change? This change enhances security by ensuring that only authenticated users can access the live chat support feature, preventing potential abuse from anonymous users and providing better user tracking for support interactions.
### TL;DR
Fixed the DSN format by swapping the token and engine namespace positions.
### What changed?
Corrected the DSN (Data Source Name) string format in the `useRivetDsn` hook. The previous implementation incorrectly placed the token before the engine namespace in the DSN URL. This PR swaps their positions to follow the correct format: `https://{engineNamespace}:{token}@{endpoint}`.
### How to test?
1. Verify that connections to the data provider work correctly with the new DSN format
2. Test both serverless and admin token scenarios to ensure proper authentication
3. Check that endpoints with both HTTP and HTTPS protocols are handled correctly
### Why make this change?
The incorrect DSN format was likely causing authentication issues when connecting to the data provider. This fix ensures that the DSN follows the expected format where the engine namespace comes before the token in the URL, which is required for proper authentication and connection to the service.
### TL;DR Added validation to ensure serverless endpoints end with `/api/rivet` ### What changed? Modified the `endpointSchema` validation in `connect-manual-serverless-form.tsx` to require that endpoints must end with `/api/rivet`. This adds an additional validation check beyond the existing requirements that the endpoint is non-empty and a valid URL. ### How to test? 1. Navigate to the manual serverless connection form 2. Try entering various endpoint URLs: - A URL that doesn't end with `/api/rivet` should show the new validation error - A URL that properly ends with `/api/rivet` should pass validation 3. Verify the error message "Endpoint must end with /api/rivet" appears when validation fails ### Why make this change? This validation ensures users provide correctly formatted endpoints that will work with our API. Adding this constraint prevents connection errors that would occur when users attempt to connect with incompatible endpoint formats.
…directs via metadata endpoint (#3891)
# Description This PR removes the unused `waitForNames` method from the `QueueManager` class and reorganizes imports across several files to improve code organization. It also fixes the Drizzle ORM exports by creating a new `sqlite-core.ts` file that re-exports specific functions from the Drizzle ORM package, rather than exporting everything directly. Additionally, the PR updates the `createFileSystemOrMemoryDriver` function to accept an options object instead of separate parameters, making the API more flexible and consistent. ## Type of change - [x] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [x] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] This change requires a documentation update ## How Has This Been Tested? The changes have been tested with the existing test suite to ensure that the removal of the unused method and the reorganization of imports don't break any functionality. ## Checklist: - [x] My code follows the style guidelines of this project - [x] I have performed a self-review of my code - [x] I have commented my code, particularly in hard-to-understand areas - [x] I have made corresponding changes to the documentation - [x] My changes generate no new warnings - [x] I have added tests that prove my fix is effective or that my feature works - [x] New and existing unit tests pass locally with my changes
# Description Please include a summary of the changes and the related issue. Please also include relevant motivation and context. ## Type of change - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] This change requires a documentation update ## How Has This Been Tested? Please describe the tests that you ran to verify your changes. ## Checklist: - [ ] My code follows the style guidelines of this project - [ ] I have performed a self-review of my code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [ ] My changes generate no new warnings - [ ] I have added tests that prove my fix is effective or that my feature works - [ ] New and existing unit tests pass locally with my changes
# Description Please include a summary of the changes and the related issue. Please also include relevant motivation and context. ## Type of change - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] This change requires a documentation update ## How Has This Been Tested? Please describe the tests that you ran to verify your changes. ## Checklist: - [ ] My code follows the style guidelines of this project - [ ] I have performed a self-review of my code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [ ] My changes generate no new warnings - [ ] I have added tests that prove my fix is effective or that my feature works - [ ] New and existing unit tests pass locally with my changes
# Description Please include a summary of the changes and the related issue. Please also include relevant motivation and context. ## Type of change - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] This change requires a documentation update ## How Has This Been Tested? Please describe the tests that you ran to verify your changes. ## Checklist: - [ ] My code follows the style guidelines of this project - [ ] I have performed a self-review of my code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [ ] My changes generate no new warnings - [ ] I have added tests that prove my fix is effective or that my feature works - [ ] New and existing unit tests pass locally with my changes
# Description Please include a summary of the changes and the related issue. Please also include relevant motivation and context. ## Type of change - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] This change requires a documentation update ## How Has This Been Tested? Please describe the tests that you ran to verify your changes. ## Checklist: - [ ] My code follows the style guidelines of this project - [ ] I have performed a self-review of my code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [ ] My changes generate no new warnings - [ ] I have added tests that prove my fix is effective or that my feature works - [ ] New and existing unit tests pass locally with my changes
# Description Please include a summary of the changes and the related issue. Please also include relevant motivation and context. ## Type of change - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] This change requires a documentation update ## How Has This Been Tested? Please describe the tests that you ran to verify your changes. ## Checklist: - [ ] My code follows the style guidelines of this project - [ ] I have performed a self-review of my code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [ ] My changes generate no new warnings - [ ] I have added tests that prove my fix is effective or that my feature works - [ ] New and existing unit tests pass locally with my changes
# Description Please include a summary of the changes and the related issue. Please also include relevant motivation and context. ## Type of change - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] This change requires a documentation update ## How Has This Been Tested? Please describe the tests that you ran to verify your changes. ## Checklist: - [ ] My code follows the style guidelines of this project - [ ] I have performed a self-review of my code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [ ] My changes generate no new warnings - [ ] I have added tests that prove my fix is effective or that my feature works - [ ] New and existing unit tests pass locally with my changes
# Description Please include a summary of the changes and the related issue. Please also include relevant motivation and context. ## Type of change - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] This change requires a documentation update ## How Has This Been Tested? Please describe the tests that you ran to verify your changes. ## Checklist: - [ ] My code follows the style guidelines of this project - [ ] I have performed a self-review of my code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [ ] My changes generate no new warnings - [ ] I have added tests that prove my fix is effective or that my feature works - [ ] New and existing unit tests pass locally with my changes
mock animation
# Description Please include a summary of the changes and the related issue. Please also include relevant motivation and context. ## Type of change - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] This change requires a documentation update ## How Has This Been Tested? Please describe the tests that you ran to verify your changes. ## Checklist: - [ ] My code follows the style guidelines of this project - [ ] I have performed a self-review of my code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [ ] My changes generate no new warnings - [ ] I have added tests that prove my fix is effective or that my feature works - [ ] New and existing unit tests pass locally with my changes
# Description Please include a summary of the changes and the related issue. Please also include relevant motivation and context. ## Type of change - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] This change requires a documentation update ## How Has This Been Tested? Please describe the tests that you ran to verify your changes. ## Checklist: - [ ] My code follows the style guidelines of this project - [ ] I have performed a self-review of my code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [ ] My changes generate no new warnings - [ ] I have added tests that prove my fix is effective or that my feature works - [ ] New and existing unit tests pass locally with my changes
…eout (#4171) # Description Please include a summary of the changes and the related issue. Please also include relevant motivation and context. ## Type of change - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] This change requires a documentation update ## How Has This Been Tested? Please describe the tests that you ran to verify your changes. ## Checklist: - [ ] My code follows the style guidelines of this project - [ ] I have performed a self-review of my code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [ ] My changes generate no new warnings - [ ] I have added tests that prove my fix is effective or that my feature works - [ ] New and existing unit tests pass locally with my changes
# Description Please include a summary of the changes and the related issue. Please also include relevant motivation and context. ## Type of change - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] This change requires a documentation update ## How Has This Been Tested? Please describe the tests that you ran to verify your changes. ## Checklist: - [ ] My code follows the style guidelines of this project - [ ] I have performed a self-review of my code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [ ] My changes generate no new warnings - [ ] I have added tests that prove my fix is effective or that my feature works - [ ] New and existing unit tests pass locally with my changes
# Description Please include a summary of the changes and the related issue. Please also include relevant motivation and context. ## Type of change - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] This change requires a documentation update ## How Has This Been Tested? Please describe the tests that you ran to verify your changes. ## Checklist: - [ ] My code follows the style guidelines of this project - [ ] I have performed a self-review of my code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [ ] My changes generate no new warnings - [ ] I have added tests that prove my fix is effective or that my feature works - [ ] New and existing unit tests pass locally with my changes
# Description Please include a summary of the changes and the related issue. Please also include relevant motivation and context. ## Type of change - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] This change requires a documentation update ## How Has This Been Tested? Please describe the tests that you ran to verify your changes. ## Checklist: - [ ] My code follows the style guidelines of this project - [ ] I have performed a self-review of my code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [ ] My changes generate no new warnings - [ ] I have added tests that prove my fix is effective or that my feature works - [ ] New and existing unit tests pass locally with my changes
# Description Please include a summary of the changes and the related issue. Please also include relevant motivation and context. ## Type of change - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] This change requires a documentation update ## How Has This Been Tested? Please describe the tests that you ran to verify your changes. ## Checklist: - [ ] My code follows the style guidelines of this project - [ ] I have performed a self-review of my code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [ ] My changes generate no new warnings - [ ] I have added tests that prove my fix is effective or that my feature works - [ ] New and existing unit tests pass locally with my changes
# Description Please include a summary of the changes and the related issue. Please also include relevant motivation and context. ## Type of change - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] This change requires a documentation update ## How Has This Been Tested? Please describe the tests that you ran to verify your changes. ## Checklist: - [ ] My code follows the style guidelines of this project - [ ] I have performed a self-review of my code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [ ] My changes generate no new warnings - [ ] I have added tests that prove my fix is effective or that my feature works - [ ] New and existing unit tests pass locally with my changes
railway-app
bot
temporarily deployed
to
rivet-frontend / rivet-pr-4199
|
🚅 Deployed to the rivet-pr-4199 environment in rivet-frontend
|
graphite-app
bot
changed the base branch from
02-12-chore_move_k8s_in_to_deploy_folder
to
main
Member
Author
How to use the Graphite Merge QueueAdd the label merge-queue to this PR to add it to the merge queue. You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
This was referenced Feb 16, 2026
PR Review: Documentation ReorganizationSummaryThis PR reorganizes documentation and deployment files for cleaner navigation. The changes include:
Files Changed: 35 files (+27/-41 lines) Positive Aspects✅ Clear organizational improvement - Consolidating documentation from multiple scattered locations ( ✅ Logical separation - The ✅ Documentation enhancement - The new content in ✅ Agent-friendly changes - The new CLAUDE.md section about Issues & Concerns1. Missing Broken Link Updates
|
1 task
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
5 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.
Description
Please include a summary of the changes and the related issue. Please also include relevant motivation and context.
Type of change
How Has This Been Tested?
Please describe the tests that you ran to verify your changes.
Checklist: