chore: release v4.5.14

[github-actions]

Summary

4 improvements, 1 bug fix.

Improvements

• Native build server deploys now show a single updating build log line by default; pass --build-logs full to stream every line (always used in CI and when output is not a terminal). (#4817)

• Realtime stream subscriptions can now refresh an expired access token and reconnect, via a new optional refreshAccessToken option on the client configuration and the React hooks. (#4811)

• Subscribe to a realtime stream from its latest record instead of replaying the whole history. Pass from: "latest" to useRealtimeStream, streams.read(), or fetchStream to start at the current tail (the latest record, then live updates) instead of replaying (a live "last value" view), and maxParts to keep the accumulated parts array bounded. A reconnect or remount resumes from the last record it saw, so no records are missed and none are replayed. from: "latest" needs a server that supports it; older servers safely fall back to a full replay. (#4811)

  useRealtimeStream also gains a lastEventId option and returns the lastEventId of the last part seen, so you can persist the cursor (for example across a page reload) and resume exactly where you left off. An onParts callback delivers each throttled batch of parts with their event ids.

  const { parts, lastEventId } = useRealtimeStream<Frame>(runId, "frames", {
  from: "latest", // skip history, start at the current tail
  maxParts: 1, // keep only the most recent frame
  lastEventId: savedCursor, // resume from a persisted cursor
  onParts: (batch) => save(batch.at(-1)?.id), // track the cursor
  accessToken,
  });

• Added a useSessionStream React hook for reading a session's output or input channel in realtime. It accumulates records with automatic resume from the last record you received, and supports from: "latest" (start at the current tail, only new records after you connect), maxRecords (keep a bounded number of records in memory), a lastEventId resume cursor, and an onRecords callback that delivers each throttled batch of records with their event ids. (#4811)

Server changes

These changes affect the self-hosted Docker image and Trigger.dev Cloud:

• Task retries that wait in the queue no longer count against the queue's internal redelivery limit, so runs with many long-delay retries are not wrongly failed with TASK_RUN_DEQUEUED_MAX_RETRIES. (#4810)

Raw changeset output

Releases

@trigger.dev/build@4.5.14

Patch Changes

• Updated dependencies:
  • @trigger.dev/core@4.5.14

trigger.dev@4.5.14

Patch Changes

• Native build server deploys now show a single updating build log line by default; pass --build-logs full to stream every line (always used in CI and when output is not a terminal). (#4817)
• Updated dependencies:
  • @trigger.dev/core@4.5.14
  • @trigger.dev/build@4.5.14
  • @trigger.dev/schema-to-json@4.5.14

@trigger.dev/core@4.5.14

Patch Changes

• Realtime stream subscriptions can now refresh an expired access token and reconnect, via a new optional refreshAccessToken option on the client configuration and the React hooks. (#4811)

• Subscribe to a realtime stream from its latest record instead of replaying the whole history. Pass from: "latest" to useRealtimeStream, streams.read(), or fetchStream to start at the current tail (the latest record, then live updates) instead of replaying (a live "last value" view), and maxParts to keep the accumulated parts array bounded. A reconnect or remount resumes from the last record it saw, so no records are missed and none are replayed. from: "latest" needs a server that supports it; older servers safely fall back to a full replay. (#4811)

  useRealtimeStream also gains a lastEventId option and returns the lastEventId of the last part seen, so you can persist the cursor (for example across a page reload) and resume exactly where you left off. An onParts callback delivers each throttled batch of parts with their event ids.

  const { parts, lastEventId } = useRealtimeStream<Frame>(runId, "frames", {
    from: "latest", // skip history, start at the current tail
    maxParts: 1, // keep only the most recent frame
    lastEventId: savedCursor, // resume from a persisted cursor
    onParts: (batch) => save(batch.at(-1)?.id), // track the cursor
    accessToken,
  });

@trigger.dev/python@4.5.14

Patch Changes

• Updated dependencies:
  • @trigger.dev/core@4.5.14
  • @trigger.dev/sdk@4.5.14
  • @trigger.dev/build@4.5.14

@trigger.dev/react-hooks@4.5.14

Patch Changes

• Realtime stream subscriptions can now refresh an expired access token and reconnect, via a new optional refreshAccessToken option on the client configuration and the React hooks. (#4811)

• Subscribe to a realtime stream from its latest record instead of replaying the whole history. Pass from: "latest" to useRealtimeStream, streams.read(), or fetchStream to start at the current tail (the latest record, then live updates) instead of replaying (a live "last value" view), and maxParts to keep the accumulated parts array bounded. A reconnect or remount resumes from the last record it saw, so no records are missed and none are replayed. from: "latest" needs a server that supports it; older servers safely fall back to a full replay. (#4811)

  useRealtimeStream also gains a lastEventId option and returns the lastEventId of the last part seen, so you can persist the cursor (for example across a page reload) and resume exactly where you left off. An onParts callback delivers each throttled batch of parts with their event ids.

  const { parts, lastEventId } = useRealtimeStream<Frame>(runId, "frames", {
    from: "latest", // skip history, start at the current tail
    maxParts: 1, // keep only the most recent frame
    lastEventId: savedCursor, // resume from a persisted cursor
    onParts: (batch) => save(batch.at(-1)?.id), // track the cursor
    accessToken,
  });

• Added a useSessionStream React hook for reading a session's output or input channel in realtime. It accumulates records with automatic resume from the last record you received, and supports from: "latest" (start at the current tail, only new records after you connect), maxRecords (keep a bounded number of records in memory), a lastEventId resume cursor, and an onRecords callback that delivers each throttled batch of records with their event ids. (#4811)

• Updated dependencies:

  • @trigger.dev/core@4.5.14

@trigger.dev/redis-worker@4.5.14

Patch Changes

• Updated dependencies:
  • @trigger.dev/core@4.5.14

@trigger.dev/rsc@4.5.14

Patch Changes

• Updated dependencies:
  • @trigger.dev/core@4.5.14

@trigger.dev/schema-to-json@4.5.14

Patch Changes

• Updated dependencies:
  • @trigger.dev/core@4.5.14

@trigger.dev/sdk@4.5.14

Patch Changes

• Subscribe to a realtime stream from its latest record instead of replaying the whole history. Pass from: "latest" to useRealtimeStream, streams.read(), or fetchStream to start at the current tail (the latest record, then live updates) instead of replaying (a live "last value" view), and maxParts to keep the accumulated parts array bounded. A reconnect or remount resumes from the last record it saw, so no records are missed and none are replayed. from: "latest" needs a server that supports it; older servers safely fall back to a full replay. (#4811)

  useRealtimeStream also gains a lastEventId option and returns the lastEventId of the last part seen, so you can persist the cursor (for example across a page reload) and resume exactly where you left off. An onParts callback delivers each throttled batch of parts with their event ids.

  const { parts, lastEventId } = useRealtimeStream<Frame>(runId, "frames", {
    from: "latest", // skip history, start at the current tail
    maxParts: 1, // keep only the most recent frame
    lastEventId: savedCursor, // resume from a persisted cursor
    onParts: (batch) => save(batch.at(-1)?.id), // track the cursor
    accessToken,
  });

• Updated dependencies:

  • @trigger.dev/core@4.5.14

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.