Hi team, trying to understand more on how the run_...
# ask-community
h
Hi team, trying to understand more on how the run_status_sensor works. We have @run_status_sensor(run_status=QUEUED) but it seems to get skipped even when there were jobs being queued between its tick
i.e. The sensor skipped past 3 ticks from 2:06 to 2:37. However, we see that there are jobs being queued around 2:11.
y
what’s the record_id for the run that got queued? one hunch could be as at record_id cursors were at 95629203, 95629334, 95629453, the run status sensor might have missed that queued run somehow.
h
Thanks @yuhan! What’s the easiest way to get the record_id for a run please?
@yuhan following up on this 🙏
y
sorry! looking now
we don’t surface that through the UI but you can get it through
DagsterInstance.get_run_record_by_id(run_id)
https://github.com/dagster-io/dagster/blob/master/python_modules/dagster/dagster/_core/instance/__init__.py#L937
👍 1
the record_id is auto incremented so that would help to determine when and which runs the run status sensor skipped
h
Thanks. Let me try it. Another question, is there a way to see the job run for these sensors?
y
by job run, did you mean the skipped runs, or the sensor body?
h
the jobs that are triggered by the job status sensors
y
to clarify, does your run status sensor kick off any new runs? — in most cases it should be listening to any skipped runs (run_A) and do something in the sensor body (in my_run_status_sensor), such as:
Copy code
run_A -> my_run_status_sensor
if my_run_status_sensor did react to run_A, in run_A’s log, you should be seeing something like:
Sensor … acted on run status ... of run ...
h
My run status sensor doesn’t kick off any new runs. We only want it to monitor job success/fail and emit metrics for now. I just realized that the run status sensor directly executes the job inside our server pod instead of creating a dagster job to execute the code inside it. Is it the case?