The cloud-native orchestrator for the whole development lifecycle, with integrated lineage and observability.

dagster

image.png

:white_check_mark: *SOLVED*

:point_right: I was not specifying `repository_name` in JobSelector and `__repository__` (the default) isn't reliable since it's a implementation detail.

_____

Hi there folks,

I'm trying to *build sensors that rely on the execution status of jobs defined via Schedules* (`build_schedule_from_dbt_selection`).

• Since there is no `job` to import I tried to use  `JobSelector` to select the job by it's name but the sensor picks *nothing.*
• If I import the `schedule` and access the `job` property things work as intended.
Any clues here?

```def make_sucessfull_job_sensor(name, trigger_jobs, request_job, run_config=None) -&gt; SensorDefinition:
    @run_status_sensor(
        name=name,
        request_job=request_job,
        run_status=DagsterRunStatus.SUCCESS,
        monitored_jobs=trigger_jobs,
        default_status=DefaultSensorStatus.RUNNING,
    )
    def _successful_job_sensor(context: RunStatusSensorContext):
        yield RunRequest(run_key=f"triggered_by_{context.dagster_run.run_id}", run_config=run_config)

    return _successful_job_sensor```


you can specify the job name via `job_name` in `build_schedule_from_dbt_selection`, then in `run_status_sensor`, you can provide the job name to `JobSelector`

```brain_assets_schedule = build_schedule_from_dbt_selection(
    dbt_assets=[arado_dbt_assets],
    job_name="brain_assets_job",
    dbt_select="stg_brain__warehouse",
    cron_schedule="@hourly",
)```
job names are matching :sadblob:

are you using `Definitions` and are both the sensor and the schedule provided there?

Yeap! The they both load up just fine on the UI

found the issue!

I omitted `repository_name` since it gets the default from dunder repository but... When I harcoded it worked :T

```defs = create_repository_using_definitions_args(
    name="dagarado",
    assets=all_assets,
    resources=resources_by_deployment_name[get_deployment_name()],
    jobs=all_jobs,
    executor=in_process_executor,
    schedules=all_schedules,
    sensors=all_sensors,
)```

i’d actually recommend using the `schedule.job` as hardcoding str might be hard to maintain.

Not sure where `__repository___` comes from

Yeap, before `build_schedule_from_dbt_selection` appeared we were passing jobs all 'round! After it our code got DRY-ish and the jobs were gone.

But since I can access the `job` property there is no issue :slightly_smiling_face:

`__repository__` is kinda an implementation detail. “definition” used to be “repository” (<https://github.com/dagster-io/dagster/discussions/11167>) so internal representation wise it’s still going through the repository abstraction, in order to maintain backward compatibility.

It's a pleasure to navigate through the source code, btw :surfer:

Always learning something new!

Thanks for the pointers and explanations, yuhan!