-
-
Notifications
You must be signed in to change notification settings - Fork 705
Associate child runs with the parent span ID #1352
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,5 @@ | ||
--- | ||
"@trigger.dev/core": patch | ||
--- | ||
|
||
Add otel propagation headers "below" the API fetch span, to attribute the child runs with the proper parent span ID |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,38 @@ | ||
## @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 add a new index on a large table | ||
|
||
1. Modify the Prisma.schema with a single index change (no other changes, just one index at a time) | ||
2. Create a Prisma migration using `cd packages/database && pnpm run db:migrate:dev --create-only` | ||
3. Modify the SQL file: add IF NOT EXISTS to it and CONCURRENTLY: | ||
|
||
```sql | ||
CREATE INDEX CONCURRENTLY IF NOT EXISTS "JobRun_eventId_idx" ON "JobRun" ("eventId"); | ||
``` | ||
|
||
4. Don’t apply the Prisma migration locally yet. This is a good opportunity to test the flow. | ||
5. Manually apply the index to your database, by running the index command. | ||
6. Then locally run `pnpm run db:migrate:deploy` | ||
|
||
#### Before deploying | ||
|
||
Run the index creation before deploying | ||
|
||
```sql | ||
CREATE INDEX CONCURRENTLY IF NOT EXISTS "JobRun_eventId_idx" ON "JobRun" ("eventId"); | ||
``` | ||
|
||
These commands are useful: | ||
|
||
```sql | ||
-- 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. | ||
Comment on lines
+1
to
+38
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 💡 Codebase verification Inconsistency in index naming found in documentation and migrations. The verification script revealed multiple instances of the unexpected index name "JobRun_eventId_idx" in the following files:
To maintain consistency with the PR objectives, please update these occurrences to "TaskRun_rootTaskRunId_idx". Analysis chainOverall, excellent documentation for database index management. This README provides comprehensive and well-structured guidance for managing database indexes in the @trigger.dev/database package. The instructions are clear, follow best practices, and align well with the PR objectives for database optimization. To ensure consistency throughout the documentation and codebase, please run the following script to verify the correct index name usage: After running this script, ensure that all occurrences of "JobRun_eventId_idx" are replaced with "TaskRun_rootTaskRunId_idx" to maintain consistency with the PR objectives. Scripts executedThe following scripts were executed for the analysis: Script: #!/bin/bash
# Description: Verify the correct index name is used consistently.
# Test: Search for both index names. Expect: Only occurrences of "TaskRun_rootTaskRunId_idx".
echo "Searching for 'TaskRun_rootTaskRunId_idx' (expected):"
rg --type sql --type md "TaskRun_rootTaskRunId_idx"
echo "\nSearching for 'JobRun_eventId_idx' (unexpected):"
rg --type sql --type md "JobRun_eventId_idx"
Length of output: 1167 |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,2 @@ | ||
-- CreateIndex | ||
CREATE INDEX CONCURRENTLY IF NOT EXISTS "TaskRun_rootTaskRunId_idx" ON "TaskRun"("rootTaskRunId"); |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,2 @@ | ||
-- AlterTable | ||
ALTER TABLE "TaskRun" ADD COLUMN "parentSpanId" TEXT; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Simplify context propagation by injecting directly into
Headers
Instead of converting
Headers
to an object and back, you can inject directly into theHeaders
instance. This simplifies the code and avoids potential issues with header case sensitivity.Apply this diff to inject directly into the
Headers
object:By injecting directly into
headers
, you leverage the built-in behavior ofpropagation.inject
when working withHeaders
objects.Committable suggestion