Ran into an issue when testing a schedule for a static-partitioned asset. I saw that

run_request_for_partition

is deprecated, so I switched to yielding a

RunRequest

but now I get this:

dagster._core.errors.DagsterInvariantViolationError: Attempted to access repository_def, but no repository_def was provided.
  File "/usr/local/lib/python3.10/site-packages/dagster/_grpc/impl.py", line 329, in get_external_schedule_execution
    return schedule_def.evaluate_tick(schedule_context)
  File "/usr/local/lib/python3.10/site-packages/dagster/_core/definitions/schedule_definition.py", line 774, in evaluate_tick
    if context.repository_def is None:
  File "/usr/local/lib/python3.10/site-packages/dagster/_core/definitions/schedule_definition.py", line 305, in repository_def
    raise DagsterInvariantViolationError(

@claire - are you able to take a look at this one?

yep, @Charlie Bini would you mind sharing a code snippet of what you're doing in the unit test and how you created your schedule context?

yup, I've since reverted it, but here's where the schedule definition happens: https://github.com/TEAMSchools/teamster/blob/3453fc08f8f93424cb6f406f2f3a877f11f20d0b/src/teamster/kipptaf/schoolmint/schedules.py#L9-L23

I think you'll need to add

repository_def

to

build_schedule_context

. This is because we now allow defining a schedule with just the job name, and yielding a run request for that job, which means that we have to load the repository to validate the partition when only the job name is provided

so don't use the schedule decorator?

Though I think we can fix this issue when the job is directly provided to the schedule, as you did in your code

oh I see, this isn't happening on a literal unit test. I'm trying it out in our staging environment and it pops up when I click Test Schedule

ahhh I see. I'll take a look at this

presumably it would error out in the same way after a schedule tick

thanks for reporting, https://github.com/dagster-io/dagster/pull/13429 will fix this in the next release