SchedulerDaemon removes the state of dagster UI changes

[m-borkowski]

What's the issue?

Hi, I couldn't find information about this in other issues.

When I use dagster UI, and I want to change the state of a schedule switch from stopped to running, after a while the SchedulerDaemon returns it to the default value defined in the code.
Analogously happens when the default state is running and I change it to stopped.

In the logs I get such information:

dagster.daemon.SchedulerDaemon - INFO - Removing state for schedule test_schedule that is no longer present in __init__.py.

How to disable this SchedulerDaemon feature so it doesn't revert to default settings after a change?

What did you expect to happen?

I expect that after change of schedule/sensor status via UI, the change will be permanent and not reverted to the default state.

How to reproduce?

Create any schedule using dagster version 1.8.13 and try to change the status of the schedule via UI

Dagster version

1.8.13

Deployment type

Other Docker-based deployment

Deployment details

It appears both locally when running dagster with docker-compose and in a cloud setup based on a docker image.

Additional information

No response

Message from the maintainers

Impacted by this issue? Give it a 👍! We factor engagement into prioritization.
By submitting this issue, you agree to follow Dagster's Code of Conduct.

[gibsondan]

Hi @m-borkowski - I would only expect this to happen if your daemon is unaware that the schedule exists (i.e. when it tries to see what schedules are there by loading the code location, it can't find the schedule). Are you sure that your daemon and your webserver are using the same code? Can you share more about your deployment setup / what your workspace.yaml looks like?

[gibsondan]

in particular, i would not expect this to happen if your webserver and daemon are loading code via a code server container: https://docs.dagster.io/deployment/guides/docker#multi-container-docker-deployment

(But i also would not expect it to happen if they are both loading the same code locally, as long as the code is the same in both containers - you will need that anyway if you want your schedule to actually run)