Have a way of configuring sequence on which resources are deleted on tilt down to handle CRDs Operators that write `finalizer` keys on CR

I’m currently using tilt to setup a complete set of micro services, which includes:

• an app called hydra (https://github.com/ory/hydra), that also creates a CRD “Oauth2CLient”
• a related CRD Operator called Hydra Maester (https://github.com/ory/hydra-maester)
• a custom CR of kind Oauth2Client

The hydra CRD operator (hydra maester) is watching on CR of kind Oauth2Client for their creation and deletion in order to create / delete associated record in the hydra database.

As the operator wants to be “sure” to get the CRD deletion signal, it writes a custom finalizer key on the CR to prevent Kubernetes to delete those CR before the Operator can process their deletion. When the Operator has processed the CR deletion it removes the finalizer key and Kubernetes can delete the CR.

However, when running tilt down it appears that the CRD Operator (hydra maester) is deleted before the CR is deleted.
When tilt try to delete the CR, Kubernetes blocks due to the finalizer key written in the CR, but sadly the Operator (hydra maester) responsible for removing this key was already deleted so it’s not getting the deletion signal and doesn’t remove the finalizer key.

Hence everything hangs up on tilt down.

Is there a way to ask tilt to have kind of “down dependencies” and respect those when creating the order in which resource should be deleted?

Current workaround discussed on Slack is:

if config.tilt_subcommand == "down":
  local('kubectl delete insertmycr')

to delete synchronously the CR during the Tiltfile evaluation.

The issue provides no file or test entry point. Start by reproducing the hydra-maester finalizer scenario with the documented kubectl workaround, then inspect how Tilt determines deletion order; done means tilt down handles the CR and operator lifecycle without hanging.