Hi - is there an easy way to convert a job definition + config into a run request? Or is there a clean way to have a sensor trigger a follow on job (that doesn't necessarily have the exact same config params as the job/op that triggered it)?

when you say to have a sensor trigger a follow on job, did you mean re-executing the same job but maybe with different config?

@yuhan No, I'm basically trying to have a sensor detect job 1 finishes triggering job 2. We have a schedule based system that works at the moment, but it's not the best case scenario as we have mistimings occasionally.

got it. here’s a github discussion that addressed a similar cross-job dependency to your scenario: https://github.com/dagster-io/dagster/discussions/8484

Thanks for that, however, I'm mostly curious about turning a job into a run request. The docs / git link you sent seem to indicate that I'd still have to generate a run request. If I have a job definition on hand + the config that goes with it, what's the easiest way to generate the run request?

with a job definition and the config, you can do:

@sensor(job=my_job_def)
def my_sensor():
    yield RunRequest(
        run_key=...,
        run_config=run_config,
    )

😕 we're using 0.15.2 for the dagster version. Looking through everything, it seems like a lot has changed with sensors in the last few months. Going to try to convince my team to upgrade haha. Sorry for the questions - the newer versions make it seem like sensors are a lot more streamlined.

looking at the 0.15.2 sensor’s api doc: https://docs.dagster.io/0.15.2/_apidocs/schedules-sensors#sensors the

job

arg was available back then. so that code snippet should work in 0.15.2 too

Odd when I apply it to run status sensor in 0.15.2, it comes back that it doesn't have a job parameter. Despite inheriting from sensor. It also doesn't show up in the tooltip docstring on the declarator either in vscode :/