Skip to content

Commit cc9ca95

Browse files
authored
Merge branch 'main' into docs/remove-old-warning
2 parents b4e72a4 + 68e88d0 commit cc9ca95

File tree

318 files changed

+27183
-2174
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

318 files changed

+27183
-2174
lines changed

.changeset/chilly-tips-explode.md

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
---
2+
"trigger.dev": patch
3+
---
4+
5+
Add platform notifications support to the CLI. The `trigger dev` and `trigger login` commands now fetch and display platform notifications (info, warn, error, success) from the server. Includes discovery-based filtering to conditionally show notifications based on project file patterns, color markup rendering for styled terminal output, and a non-blocking display flow with a spinner fallback for slow fetches. Use `--skip-platform-notifications` flag with `trigger dev` to disable the notification check.

.changeset/fix-local-build-load.md

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
---
2+
"trigger.dev": patch
3+
---
4+
5+
Fix `--load` flag being silently ignored on local/self-hosted builds.
Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
---
2+
"@trigger.dev/core": patch
3+
---
4+
5+
Large run outputs can use the new API which allows switching object storage providers.
Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
---
2+
"@trigger.dev/core": patch
3+
---
4+
5+
Add optional `hasPrivateLink` field to the dequeue message organization object for private networking support

.changeset/quiet-dogs-fly.md

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,7 @@
1+
---
2+
"@trigger.dev/sdk": patch
3+
"@trigger.dev/core": patch
4+
"trigger.dev": patch
5+
---
6+
7+
Add support for setting TTL (time-to-live) defaults at the task level and globally in trigger.config.ts, with per-trigger overrides still taking precedence
Lines changed: 78 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,78 @@
1+
---
2+
name: span-timeline-events
3+
description: Use when adding, modifying, or debugging OTel span timeline events in the trace view. Covers event structure, ClickHouse storage constraints, rendering in SpanTimeline component, admin visibility, and the step-by-step process for adding new events.
4+
allowed-tools: Read, Write, Edit, Glob, Grep, Bash
5+
---
6+
7+
# Span Timeline Events
8+
9+
The trace view's right panel shows a timeline of events for the selected span. These are OTel span events rendered by `app/utils/timelineSpanEvents.ts` and the `SpanTimeline` component.
10+
11+
## How They Work
12+
13+
1. **Span events** in OTel are attached to a parent span. In ClickHouse, they're stored as separate rows with `kind: "SPAN_EVENT"` sharing the parent span's `span_id`. The `#mergeRecordsIntoSpanDetail` method reassembles them into the span's `events` array at query time.
14+
2. The timeline only renders events whose `name` starts with `trigger.dev/` - all others are silently filtered out.
15+
3. The **display name** comes from `properties.event` (not the span event name), mapped through `getFriendlyNameForEvent()`.
16+
4. Events are shown on the **span they belong to** - events on one span don't appear in another span's timeline.
17+
18+
## ClickHouse Storage Constraint
19+
20+
When events are written to ClickHouse, `spanEventsToTaskEventV1Input()` filters out events whose `start_time` is not greater than the parent span's `startTime`. Events at or before the span start are silently dropped. This means span events must have timestamps strictly after the span's own `startTimeUnixNano`.
21+
22+
## Timeline Rendering (SpanTimeline component)
23+
24+
The `SpanTimeline` component in `app/components/run/RunTimeline.tsx` renders:
25+
26+
1. **Events** (thin 1px line with hollow dots) - all events from `createTimelineSpanEventsFromSpanEvents()`
27+
2. **"Started"** marker (thick cap) - at the span's `startTime`
28+
3. **Duration bar** (thick 7px line) - from "Started" to "Finished"
29+
4. **"Finished"** marker (thick cap) - at `startTime + duration`
30+
31+
The thin line before "Started" only appears when there are events with timestamps between the span start and the first child span. For the Attempt span this works well (Dequeued -> Pod scheduled -> Launched -> etc. all happen before execution starts). Events all get `lineVariant: "light"` (thin) while the execution bar gets `variant: "normal"` (thick).
32+
33+
## Trace View Sort Order
34+
35+
Sibling spans (same parent) are sorted by `start_time ASC` from the ClickHouse query. The `createTreeFromFlatItems` function preserves this order. Event timestamps don't affect sort order - only the span's own `start_time`.
36+
37+
## Event Structure
38+
39+
```typescript
40+
// OTel span event format
41+
{
42+
name: "trigger.dev/run", // Must start with "trigger.dev/" to render
43+
timeUnixNano: "1711200000000000000",
44+
attributes: [
45+
{ key: "event", value: { stringValue: "dequeue" } }, // The actual event type
46+
{ key: "duration", value: { intValue: 150 } }, // Optional: duration in ms
47+
]
48+
}
49+
```
50+
51+
## Admin-Only Events
52+
53+
`getAdminOnlyForEvent()` controls visibility. Events default to **admin-only** (`true`).
54+
55+
| Event | Admin-only | Friendly name |
56+
|-------|-----------|---------------|
57+
| `dequeue` | No | Dequeued |
58+
| `fork` | No | Launched |
59+
| `import` | No (if no fork event) | Importing task file |
60+
| `create_attempt` | Yes | Attempt created |
61+
| `lazy_payload` | Yes | Lazy attempt initialized |
62+
| `pod_scheduled` | Yes | Pod scheduled |
63+
| (default) | Yes | (raw event name) |
64+
65+
## Adding New Timeline Events
66+
67+
1. Add OTLP span event with `name: "trigger.dev/<scope>"` and `properties.event: "<type>"`
68+
2. Event timestamp must be strictly after the parent span's `startTimeUnixNano` (ClickHouse drops earlier events)
69+
3. Add friendly name in `getFriendlyNameForEvent()` in `app/utils/timelineSpanEvents.ts`
70+
4. Set admin visibility in `getAdminOnlyForEvent()`
71+
5. Optionally add help text in `getHelpTextForEvent()`
72+
73+
## Key Files
74+
75+
- `app/utils/timelineSpanEvents.ts` - filtering, naming, admin logic
76+
- `app/components/run/RunTimeline.tsx` - `SpanTimeline` component (thin line + thick bar rendering)
77+
- `app/presenters/v3/SpanPresenter.server.ts` - loads span data including events
78+
- `app/v3/eventRepository/clickhouseEventRepository.server.ts` - `spanEventsToTaskEventV1Input()` (storage filter), `#mergeRecordsIntoSpanDetail` (reassembly)

.cursor/rules/writing-tasks.mdc

Lines changed: 19 additions & 19 deletions
Original file line numberDiff line numberDiff line change
@@ -14,7 +14,7 @@ alwaysApply: false
1414

1515
## Essential requirements when generating task code
1616

17-
1. You MUST use `@trigger.dev/sdk/v3`
17+
1. You MUST import from `@trigger.dev/sdk` (NEVER `@trigger.dev/sdk/v3`)
1818
2. You MUST NEVER use `client.defineJob`
1919
3. YOU MUST `export` every task, including subtasks
2020
4. If you are able to generate an example payload for a task, do so.
@@ -53,7 +53,7 @@ Instead, you MUST ALWAYS generate ONLY this pattern:
5353
```ts
5454
// ✅ ALWAYS GENERATE THIS EXACT PATTERN
5555

56-
import { task } from "@trigger.dev/sdk/v3";
56+
import { task } from "@trigger.dev/sdk";
5757

5858
//1. You need to export each task, even if it's a subtask
5959
export const helloWorld = task({
@@ -71,7 +71,7 @@ export const helloWorld = task({
7171
A task is a function that can run for a long time with resilience to failure:
7272

7373
```ts
74-
import { task } from "@trigger.dev/sdk/v3";
74+
import { task } from "@trigger.dev/sdk";
7575

7676
export const helloWorld = task({
7777
id: "hello-world",
@@ -271,7 +271,7 @@ Global lifecycle hooks can also be defined in `trigger.config.ts` to apply to al
271271
## Correct Schedules task (cron) implementations
272272

273273
```ts
274-
import { schedules } from "@trigger.dev/sdk/v3";
274+
import { schedules } from "@trigger.dev/sdk";
275275

276276
export const firstScheduledTask = schedules.task({
277277
id: "first-scheduled-task",
@@ -312,7 +312,7 @@ export const firstScheduledTask = schedules.task({
312312
### Attach a Declarative schedule
313313

314314
```ts
315-
import { schedules } from "@trigger.dev/sdk/v3";
315+
import { schedules } from "@trigger.dev/sdk";
316316

317317
// Sepcify a cron pattern (UTC)
318318
export const firstScheduledTask = schedules.task({
@@ -326,7 +326,7 @@ export const firstScheduledTask = schedules.task({
326326
```
327327

328328
```ts
329-
import { schedules } from "@trigger.dev/sdk/v3";
329+
import { schedules } from "@trigger.dev/sdk";
330330

331331
// Specify a specific timezone like this:
332332
export const secondScheduledTask = schedules.task({
@@ -375,7 +375,7 @@ const createdSchedule = await schedules.create({
375375
Schema tasks validate payloads against a schema before execution:
376376

377377
```ts
378-
import { schemaTask } from "@trigger.dev/sdk/v3";
378+
import { schemaTask } from "@trigger.dev/sdk";
379379
import { z } from "zod";
380380

381381
const myTask = schemaTask({
@@ -400,7 +400,7 @@ When you trigger a task from your backend code, you need to set the `TRIGGER_SEC
400400
Triggers a single run of a task with specified payload and options without importing the task. Use type-only imports for full type checking.
401401

402402
```ts
403-
import { tasks } from "@trigger.dev/sdk/v3";
403+
import { tasks } from "@trigger.dev/sdk";
404404
import type { emailSequence } from "~/trigger/emails";
405405

406406
export async function POST(request: Request) {
@@ -418,7 +418,7 @@ export async function POST(request: Request) {
418418
Triggers multiple runs of a single task with different payloads without importing the task.
419419

420420
```ts
421-
import { tasks } from "@trigger.dev/sdk/v3";
421+
import { tasks } from "@trigger.dev/sdk";
422422
import type { emailSequence } from "~/trigger/emails";
423423

424424
export async function POST(request: Request) {
@@ -436,7 +436,7 @@ export async function POST(request: Request) {
436436
Triggers multiple runs of different tasks at once, useful when you need to execute multiple tasks simultaneously.
437437

438438
```ts
439-
import { batch } from "@trigger.dev/sdk/v3";
439+
import { batch } from "@trigger.dev/sdk";
440440
import type { myTask1, myTask2 } from "~/trigger/myTasks";
441441

442442
export async function POST(request: Request) {
@@ -621,7 +621,7 @@ const handle = await myTask.trigger(
621621
Access metadata inside a run:
622622

623623
```ts
624-
import { task, metadata } from "@trigger.dev/sdk/v3";
624+
import { task, metadata } from "@trigger.dev/sdk";
625625

626626
export const myTask = task({
627627
id: "my-task",
@@ -713,7 +713,7 @@ Trigger.dev Realtime enables subscribing to runs for real-time updates on run st
713713
Subscribe to a run after triggering a task:
714714

715715
```ts
716-
import { runs, tasks } from "@trigger.dev/sdk/v3";
716+
import { runs, tasks } from "@trigger.dev/sdk";
717717

718718
async function myBackend() {
719719
const handle = await tasks.trigger("my-task", { some: "data" });
@@ -735,7 +735,7 @@ async function myBackend() {
735735
You can infer types of run's payload and output by passing the task type:
736736

737737
```ts
738-
import { runs } from "@trigger.dev/sdk/v3";
738+
import { runs } from "@trigger.dev/sdk";
739739
import type { myTask } from "./trigger/my-task";
740740

741741
for await (const run of runs.subscribeToRun<typeof myTask>(handle.id)) {
@@ -752,7 +752,7 @@ for await (const run of runs.subscribeToRun<typeof myTask>(handle.id)) {
752752
Stream data in realtime from inside your tasks using the metadata system:
753753

754754
```ts
755-
import { task, metadata } from "@trigger.dev/sdk/v3";
755+
import { task, metadata } from "@trigger.dev/sdk";
756756
import OpenAI from "openai";
757757

758758
export type STREAMS = {
@@ -947,7 +947,7 @@ For most use cases, Realtime hooks are preferred over SWR hooks with polling due
947947
For client-side usage, generate a public access token with appropriate scopes:
948948

949949
```ts
950-
import { auth } from "@trigger.dev/sdk/v3";
950+
import { auth } from "@trigger.dev/sdk";
951951

952952
const publicToken = await auth.createPublicToken({
953953
scopes: {
@@ -967,7 +967,7 @@ Idempotency ensures that an operation produces the same result when called multi
967967
Provide an `idempotencyKey` when triggering a task to ensure it runs only once with that key:
968968

969969
```ts
970-
import { idempotencyKeys, task } from "@trigger.dev/sdk/v3";
970+
import { idempotencyKeys, task } from "@trigger.dev/sdk";
971971

972972
export const myTask = task({
973973
id: "my-task",
@@ -1058,7 +1058,7 @@ function hash(payload: any): string {
10581058

10591059
```ts
10601060
// onFailure executes after all retries are exhausted; use for notifications, logging, or side effects on final failure:
1061-
import { task, logger } from "@trigger.dev/sdk/v3";
1061+
import { task, logger } from "@trigger.dev/sdk";
10621062

10631063
export const loggingExample = task({
10641064
id: "logging-example",
@@ -1078,7 +1078,7 @@ export const loggingExample = task({
10781078
The `trigger.config.ts` file configures your Trigger.dev project, specifying task locations, retry settings, telemetry, and build options.
10791079

10801080
```ts
1081-
import { defineConfig } from "@trigger.dev/sdk/v3";
1081+
import { defineConfig } from "@trigger.dev/sdk";
10821082

10831083
export default defineConfig({
10841084
project: "<project ref>",
@@ -1226,7 +1226,7 @@ await myTask.trigger({ name: "Alice", age: 30 });
12261226

12271227
Before generating any code, you MUST verify:
12281228

1229-
1. Are you importing from `@trigger.dev/sdk/v3`? If not, STOP and FIX.
1229+
1. Are you importing from `@trigger.dev/sdk` (NOT `@trigger.dev/sdk/v3`)? If not, STOP and FIX.
12301230
2. Have you exported every task? If not, STOP and FIX.
12311231
3. Have you generated any DEPRECATED code patterns? If yes, STOP and FIX.
12321232

.env.example

Lines changed: 22 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -77,9 +77,28 @@ POSTHOG_PROJECT_KEY=
7777
# DEPOT_TOKEN=<Depot org token>
7878
# DEV_OTEL_EXPORTER_OTLP_ENDPOINT="http://0.0.0.0:4318"
7979
# These are needed for the object store (for handling large payloads/outputs)
80-
# OBJECT_STORE_BASE_URL="https://{bucket}.{accountId}.r2.cloudflarestorage.com"
81-
# OBJECT_STORE_ACCESS_KEY_ID=
82-
# OBJECT_STORE_SECRET_ACCESS_KEY=
80+
#
81+
# Default provider
82+
# OBJECT_STORE_BASE_URL=http://localhost:9005
83+
# OBJECT_STORE_BUCKET=packets
84+
# OBJECT_STORE_ACCESS_KEY_ID=minioadmin
85+
# OBJECT_STORE_SECRET_ACCESS_KEY=minioadmin
86+
# OBJECT_STORE_REGION=us-east-1
87+
# OBJECT_STORE_SERVICE=s3
88+
#
89+
# OBJECT_STORE_DEFAULT_PROTOCOL=s3 # Only specify this if you're going to migrate object storage and set protocol values below
90+
# Named providers (protocol-prefixed data) - optional for multi-provider support
91+
# OBJECT_STORE_S3_BASE_URL=https://s3.amazonaws.com
92+
# OBJECT_STORE_S3_ACCESS_KEY_ID=
93+
# OBJECT_STORE_S3_SECRET_ACCESS_KEY=
94+
# OBJECT_STORE_S3_REGION=us-east-1
95+
# OBJECT_STORE_S3_SERVICE=s3
96+
#
97+
# OBJECT_STORE_R2_BASE_URL=https://{bucket}.{accountId}.r2.cloudflarestorage.com
98+
# OBJECT_STORE_R2_ACCESS_KEY_ID=
99+
# OBJECT_STORE_R2_SECRET_ACCESS_KEY=
100+
# OBJECT_STORE_R2_REGION=auto
101+
# OBJECT_STORE_R2_SERVICE=s3
83102
# CHECKPOINT_THRESHOLD_IN_MS=10000
84103

85104
# These control the server-side internal telemetry
Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,6 @@
1+
---
2+
area: webapp
3+
type: feature
4+
---
5+
6+
Add admin UI for viewing and editing feature flags (org-level overrides and global defaults).
Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,6 @@
1+
---
2+
area: webapp
3+
type: feature
4+
---
5+
6+
Pre-warm compute templates on deploy for orgs with compute access. Required for projects using a compute region, background-only for others.

0 commit comments

Comments
 (0)