LGTM. Symmetric with the existing restriction, and the test-model alignment commit (dropping the spurious /// model-only checks) is a nice bonus — model and source now agree on what is restricted, so the proptest harness () actually exercises the new branch via the strategy that varies .

One soft nit, non-blocking: the defaulting trick on the field is load-bearing (older pipelines may lack the key) but it is a little obscure for a future reader — a brief comment would help. The new / checks correctly use -equality so a missing key on both sides compares equal without that workaround. Fine as is.

🐟

Looks good, only thing that would be handy is adding a Python test as it is e2e behavior that can be tested.

Re-APPROVE on 834e15e.

Three nice things landed since my last pass:

1. The runtime_config.hosts comparison in db/operations/pipeline.rs dropped the unwrap_or(&one) defaulting. That was an unrelated latent bug — None vs Some(1) and Some(null) would all collapse together and silently allow a transition between them. Straight equality is correct.
2. storage_class restriction added symmetrically with namespace, both source and test model.
3. The test-model ModelHelpers impl now matches source exactly — the spurious model-only checks on program_code/udf_rust/udf_toml/program_config are gone, and the storage field check (which doesn't exist in source) is replaced with the real hosts check. Model and source now agree on what is restricted, which is the whole point of the model.
4. test_runtime_config_edit_restricted[_enterprise] parameterizes the lifecycle across workers / resources.storage_mb_max / resources.namespace / resources.storage_class (+ hosts / fault_tolerance enterprise-only). Good coverage that addresses snkas's e2e ask from earlier today.

Two non-blocking nits on the python helper:

• helper_test_restricted_runtime_config_edit ends with TEST_CLIENT.patch_pipeline(name=pipeline_name, runtime_config={}) to reset between fields. That works because the test sequencing happens to leave storage cleared at that point, but it's an implicit ordering dependency between calls. A short comment ("storage is cleared by the preceding successful patch, so this empty patch is allowed") would make the chain less fragile to future edits.
• The enterprise_only test creates a fresh pipeline rather than reusing the one from test_runtime_config_edit_restricted. Fine, but if you ever wanted to assert that hosts / fault_tolerance are also gated by the storage-cleared check in non-enterprise mode (where they should silently no-op or 400), there's no coverage. Tracking-issue territory, not a blocker.