#Real Time Query

1 messages · Page 1 of 1 (latest)

lucid fjord
#

Hello! I've been playing with the Realtime API over the last couple days having watched the PR get shepherded through the process. I believe we've got a 'correct' setup in our project (albeit not certain hence the post).

We are using the auto-generated PAT from the run that is generated when we trigger a task, and then using useRealtimeRun.
We followed the advice about metadata which provides some really cool patterns to power progress updates.
It was working really nicely until a couple hours ago. I don't believe anything changed in the code but am not 100% certain.

We are getting 'something' back from the run, typically queued, sometimes queued and executing. But that's where the updates seem to stop now.
If I jump into the Trigger admin, I can see the run completed, and completed fairly quickly.
So it seems we aren't getting all updates as the status of the task goes from queued, to executing, to completed.

I can/will share any information that's relevant, but I suppose in the first instance my question is, would you ever expect to be able to log run data from useRealtimeRun, see logs with a Queued Status and an Executing Status, get no more logs, but be able to see the status is Completed in the Trigger admin?

I am basically trying to figure out if this is early teething issues around the Realtime API or if I need to investigate an issue elsewhere in my setup.

Thanks in advance!!

lucid fjord
#

A little update:

It actually seems I can get any one of the states. Sometimes it gets stuck in Queued, sometimes in Executing, and sometimes in Completed.

Here is what I think might be happening.

For a particularly short run, say on average between 1-3 seconds, we only have enough time to get one 'update' in? I'm guessing (maybe wildly wrong) there is some logic to stop emitting updates if a task is completed, or something to that effect. Is that possibly colliding with another piece of logic that says, emit a task every X seconds? So as that cycles we get one update through and then no more? Just a thought!

kind girder
#

That definitely sounds like it shouldn't be happening, I'd expect there to always be a final status update. Does it work as expected for longer runs? For example when you artificially extend their lifespan by throwing in an await wait.for({ seconds: 5 })

#

@hazy pecan probably best to look at this

hazy pecan
#

Can you send a link to one of these runs?

#

You should definitely get every update, especially the final one, but if the run is very short you might not get each metadata change. You can force the metadata to save using metadata.flush

lucid fjord
#

Thanks for the responses y'all!

@kind girder I put in a 30 second wait and that didn't resolve the problem so that rules out that idea. Thanks for the suggestion on the wait.

@hazy pecan Here's a run: https://cloud.trigger.dev/orgs/xyz-c604/projects/v3/xyz-rZ_z/runs/run_igtqo91ozscrzdkxhc1f4?span=5ba8985339eb1ac6

I can share more if helpful but here is the code that is creating the log entries:

 console.log('RunId:', runId);
 const { run, error } = useRealtimeRun(runId);
 console.log('Progress Display Run Data', run);`

And then you can see in the console screenshot we get some data through, but these were the only logs for this run.

I was seeing these okay for some time last night and this morning, but I've tried to debug a number of different ways on my side and can't quite get there.

It would seem authentication is okay since we're getting data, and the runId is correct. I'm not sure what else on my side could theoretically 'stop' listening for these updates via the useRealtimeRun hook?

hazy pecan
lucid fjord
#

No errors I can see but I didn't log errors from useRealtimeRun. I'll try that now.

#

Really similar behavior. Just got the EXECUTING status, and no errors logged.

hazy pecan
#

Yea this is very strange, I'm digging into it but it definitely seems to not be updating

lucid fjord
#

Thanks! If I can share any more context please let me know. I've been trying to debug on my end in case I implemented something incorrectly around the new APIs.

hazy pecan
#

Yea there's an issue with our electric-sql server, it's crashing and some data is being lost (just in the realtime system). I just got off a call with one of their developers and we think we know what's going on