Eric Allam
23b43be952
* WIP realtime streams * Handle realtime with large payloads or outputs #1451 * feat: optimize Redis stream handling with batching Add STREAM_ORIGIN to environment schema. Improve performance in RealtimeStreams by using TextDecoderStream for simpler text decoding and implementing batching of XADD commands for Redis streams. Limit stream size using MAXLEN option. Update environment variable repository with new variable type. Adjust import statements for Redis key and value types. * 🔧 chore: add dev dependencies for bundle analysis * add metadata tests and a few more utilties * Add stream tests and improve streaming * Added AI tool tasks, descriptions to tasks * Use the config file path to determine the workingDir, then the package.json path * Remove stream test files * useTaskTrigger react hook that allows triggering a task from the client * Add streaming support for the realtime react hooks * Add ability to stream results after useTaskTrigger * Improve the stream throttling * Use the runId as the ID key to bust the cache after triggering * Upgrade to to the latest electric sql client and server * Make realtime server backwards compat with 3.1.2 release * Pass the runId into useRealtimeRun * Fix scopes when specifiying reading all runs * WIP @trigger.dev/rsc package * Various fixes and accepted recommendations by CodeRabbit * Regenerate pnpm lock file * A couple tweaks to rsc and give up on rendering react in tasks for now * Add changeset * Remove triggerRequest from the useEffect deps * Improve realtime & frontend authentication errors * Fixed authorization tests * Remove unnecessary log * Add metadata.stream limits and improve the metadata streams structure * Streams can now have up to 2500 entries * Various coderabbit fixes * additional react-hooks jsdocs
@trigger.dev/database
This is the internal database package for the Trigger.dev project. It exports a generated prisma client that can be instantiated with a connection string.
How to switch branches when you've done migrations
Sometimes you've applied migrations and then want to switch branches without wiping out your local database.
To do this you can run the following command:
DB_VOLUME=database-data-alt pnpm run docker
This will switch to the alt volume for your local database. This database will be blank if you haven't switched to this volume before, so you'll need to follow the normal steps (in the Contributing guide) to get setup, e.g. apply migrations and seed.
To switch back to the original volume, run the following command:
pnpm run docker
How to add a new index on a large table
- Modify the Prisma.schema with a single index change (no other changes, just one index at a time)
- Create a Prisma migration using
cd internal-packages/database && pnpm run db:migrate:dev --create-only - Modify the SQL file: add IF NOT EXISTS to it and CONCURRENTLY:
CREATE INDEX CONCURRENTLY IF NOT EXISTS "JobRun_eventId_idx" ON "JobRun" ("eventId");
- Don’t apply the Prisma migration locally yet. This is a good opportunity to test the flow.
- Manually apply the index to your database, by running the index command.
- Then locally run
pnpm run db:migrate:deploy
Before deploying
Run the index creation before deploying
CREATE INDEX CONCURRENTLY IF NOT EXISTS "JobRun_eventId_idx" ON "JobRun" ("eventId");
These commands are useful:
-- creates an index safely, this can take a long time (2 mins maybe)
CREATE INDEX CONCURRENTLY IF NOT EXISTS "JobRun_eventId_idx" ON "JobRun" ("eventId");
-- checks the status of an index
SELECT * FROM pg_stat_progress_create_index WHERE relid = '"JobRun"'::regclass;
-- checks if the index is there
SELECT * FROM pg_indexes WHERE tablename = 'JobRun' AND indexname = 'JobRun_eventId_idx';
Now, when you deploy and prisma runs the migration, it will skip the index creation because it already exists. If you don't do this, there will be pain.