In 0.9.3-0.10.4 migration I'm also seeing the below error, which is quite vexing as I don't think it indicates where the problem is being generated:

Operation name: RunsRootQuery

Message: Exactly 5 or 6 columns has to be specified for iteratorexpression.

Path: ["repositoriesOrError","nodes",1,"schedules",1,"futureTicks"]

Locations: [{"line":183,"column":3}]

I'm hopeful that moving off the system cron scheduler will remediate, but any guidance is nonetheless helpful

Hi Paul. Do you mind sharing what your schedule definitions look like?

@prha Example schedule def:

def basic_example_pipeline_schedule(preset: PresetDefinition) -> ScheduleDefinition:
    """Defines the schedule for the pipeline above."""
    return ScheduleDefinition(
        name="basic_example_pipeline_every_minute",
        cron_schedule="*/5 * * * *",
        pipeline_name="basic_example_pipeline",
        mode=preset.mode,
        run_config=preset.run_config,
        environment_vars=get_environment_variables_for_scheduler()
    )

preset

looks like

PresetDefinition(
        "gcp_env_aware",
        mode="gcp",
        run_config={
            "execution": {"multiprocess": {"config": {"max_concurrent": 4}}},
            "resources": {
                "warehouse": {"config": {"project": "virta-eng-prod"}},
                "cloud_storage": {
                    "config": {
                        "bucket": os.getenv("DEFAULT_STORAGE_BUCKET"),
                        "project": "virta-eng-prod"
                    },
                },
                "io_manager": {"config": {"gcs_bucket": os.getenv("DEFAULT_STORAGE_BUCKET")}},
                "pagerduty": {"config": {"routing_key": PAGERDUTY_KEY}},
            },
        },
    )

@Paul Wyatt There’s nothing wrong with the

cron_schedule

argument that I see in your example… I suspect there’s a specific cron_schedule string that is generating the error. We do need to catch problematic cron strings earlier (at definition time?) and surface a better error message.

All schedules are the same as ones that were running on 0.9.3 successfully.

I think it’s more likely that it is a

cron_schedule

issue. With

0.10.0

we started using a cron-parsing library

croniter

to project future schedule ticks (new

0.10.0

feature). The error that’s being thrown here is by that library. Previously, with the cron scheduler, I think we just copied the cron schedule to a system crontab, which might have a more permissive structure (e.g. accepts comments)?

Ooooh there. might be a schedule followed by a comment. I'll look at the croniter docs and check our schedules 1 by 1

It’d be very helpful if you could confirm once you find the problematic schedule. In the meantime, I think

0.10.5

is being released today which will prevent the runs page from erroring out due to this issue (though the future schedule ticks view might still error).

@prha Found it. We were using an empty string for a placeholder schedule that isn't intended to run yet. Croniter doesn't like that but it perfectly comfortable with Feb 31st, so I'm rebuilding with that.

wow, very interesting. I guess this worked before because crontab allows for invalid lines, and just doesn’t run them?

The prior version of dagster cron scheduler simply wasn't writing them to the crontab