#Storing history of runs and subscribing

1 messages · Page 1 of 1 (latest)

neon valeBOT May 16, 2025, 3:01 AM

Hi @granite ruin. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

I understand you're facing challenges with the useRealtimeRunsWithTag hook causing multiple rerenders and "maximum depth error" when storing runs in a global store. Let me provide some guidance based on the available information about Trigger.dev's realtime capabilities.

Current Approach Issues

The issues you're experiencing with useRealtimeRunsWithTag and global state management are common when dealing with realtime data. The hook is designed to provide live updates, but combining it with a global store can lead to the rendering issues you're experiencing.

Alternative Approaches

1. Use Trigger.dev's Realtime API Directly

Instead of using the React hooks in multiple components and storing data in a global store, you could use the Trigger.dev Realtime API directly in your backend:

import { runs } from "@trigger.dev/sdk/v3";

// Somewhere in your backend code
for await (const run of runs.subscribeToRunsWithTag("user:1234")) {
  // Process the run data and broadcast to your clients via your websocket
  console.log(run);
}

This approach aligns with your plan to migrate to a websocket broadcasting system.

2. Consider Throttling Updates

If you still want to use the React hooks, you can use the experimental_throttleInMs option to reduce the frequency of updates:

const { runs, error } = useRealtimeRunsWithTag(tag, {
  accessToken: publicAccessToken,
  experimental_throttleInMs: 1000, // Throttle updates to once per second
});

This might help reduce the number of rerenders React hooks documentation.

3. Use the `enabled` Option

You can conditionally enable/disable the subscription based on certain conditions:

const { runs, error } = useRealtimeRunsWithTag(tag, {
  accessToken: publicAccessToken,
  enabled: shouldFetch,
});

This gives you more control over when the hook is active React hooks documentation.

Regarding Your Database Approach

Your plan to store relevant tasks and task history in a database is a valid approach, especially if you need to:

Maintain historical data beyond what Trigger.dev provides
Perform complex queries across multiple runs
Reduce dependency on the Trigger.dev API for data retrieval

This approach would allow you to use your websocket system to notify clients of updates, while the actual data comes from your database.

Known Limitations

Be aware that there's a known issue with the realtime API when subscribing to runs with large payloads (>128KB) Realtime documentation.

Recommendation

Your plan to migrate to a websocket system with database storage seems like a good approach, especially if you're dealing with complex state management across multiple users and organizations. This would give you more control over the data flow and potentially resolve the rendering issues you're experiencing.

For a reference implementation, you might want to check out the Batch LLM Evaluator example project which demonstrates a more complex realtime setup Example project.