Redeploying a flow activates inactive schedules

Bug summary

Description

When redeploying a flow that previously had an active schedule which was turned off in the UI, the inactive schedule becomes active again. Additionally, other saved fields, such as "validate parameter schedule", are reset. This behavior affects CI/CD processes and production environments in ways users may not expect.

Steps to Reproduce

Deploy a flow on a schedule.
Turn off its schedule in the UI.
Modify other fields (e.g., uncheck "validate parameter schedule").
Deploy your flow again.

Expected Behavior

The flow should redeploy with:

The schedule remaining inactive, respecting the user's choice to deactivate it in the UI.
All other manually set fields (like "validate parameter schedule") retaining their modified values.

Actual Behavior

Upon redeployment:

The previously deactivated schedule becomes active again.
Other manually set fields (like "validate parameter schedule") are reset to their default values.

Version info (`prefect version` output)

Version:             3.0.0rc17+7.g11026621aa
API version:         0.8.4
Python version:      3.12.4
Git commit:          11026621
Built:               Wed, Aug 14, 2024 11:52 PM
OS/Arch:             darwin/arm64
Profile:             default
Server type:         cloud
Pydantic version:    2.8.2

Additional context

This was a change in deployment behavior. When deployments accepted a single schedule I believe the is_schedule_active parameter at least was not overwritten. When deployments accepted multiple schedules this overwriting behavior began.

Thanks for the issue @aaazzam!

In the current era of deployments (prefect deploy, flow.deploy, flow.serve) the prefect client largely treated deployment configuration as declarative. Whatever you put in your prefect.yaml or python script (including defaults you don't know about) will be the state of the deployment we create for you. Essentially, the last one in wins, which is easy to reason about (except for the defaults that you don't know about).

It sounds like this is different from what's expected. I'll speculate that might be informed by the previous era (prefect deployment build/apply) where we would read from the server before updating a deployment to ensure we didn't change stuff that had changed in the UI.

I don't know if there is a clear expected behavior here, but if we want the prefect client to be more nuanced with updates, we'll likely need to gather and persist more metadata during deployment than we currently do.

PrefectHQ / prefect