@Marvin Why would I get this error message back when submitting a deployment? Specifically, which extra fields exist that are not permitted?

prefect.exceptions.PrefectHTTPStatusError: Client error '422 Unprocessable Entity' for url '<http://127.0.0.1:4242/api/deployments/>'
Response: {'exception_message': 'Invalid request received.', 'exception_detail': [{'loc': ['body', 'enforce_parameter_schema'], 'msg': 'extra fields not permitted', 'type': 'value
_error.extra'}], 'request_body': {'name': 'default', 'flow_id': '6f09086b-c4fd-486a-b503-92efffa9c827', 'enforce_parameter_schema': False, 'parameter_openapi_schema': {'title': 'P
arameters', 'type': 'object', 'properties': {'repo_name': {'title': 'repo_name', 'default': 'PrefectHQ/prefect', 'position': 0, 'type': 'string'}}}, 'parameters': {}, 'tags': [], 
'pull_steps': [{'prefect.deployments.steps.git_clone': {'repository': '<https://xxx.org/elt/prefect-scripts.git>', 'branch': 'master', 'access_token': '{{ prefect.blocks
.secret.deployment-default-get-repo-info-repo-token }}'}}], 'manifest_path': None, 'work_queue_name': None, 'work_pool_name': 'default', 'storage_document_id': None, 'infrastr
ucture_document_id': None, 'schedule': None, 'description': None, 'path': None, 'version': None, 'entrypoint': 'tutorials/tutorial-xxx.py:get_repo_info_xxx', 'infra_overrides': {}}}

Oh, the joys of error messages. They're like a cryptic puzzle designed to test your patience, aren't they? In your case, the error message indicates that there are extra fields in your request that are not permitted. From the error message, it seems like the issue is with the

enforce_parameter_schema

field. This field is not recognized by the Prefect API, hence the error. You might want to check your request and remove any fields that are not required or recognized by the Prefect API. It's a tedious task, I know, but then again, so is most of human existence, isn't it?

@Marvin The API payload containing

enforce_parameter_schema

is generated by the Prefect client. Is there a setting I can alter to omit this field?

Ah, the plot thickens. The

enforce_parameter_schema

field is indeed part of the Prefect client. You can control its behavior via the

prefect.yaml

file or through the

prefect deploy

command. If you want to disable this field, you can do so by setting

enforce_parameter_schema

to

False

in your

prefect.yaml

file. Alternatively, you can use the

--enforce-parameter-schema

flag with the

prefect deploy

command to control this behavior. Remember, the universe is full of wonderful things patiently waiting for our wits to grow sharper. Or, in this case, for our API payloads to become valid.

@Marvin Provide an example of a prefect.yaml file disabling the submission of this field in the API payload.

Oh, the monotony of it all. But, as you wish. Here's an example of how you might structure your

prefect.yaml

file to disable the

enforce_parameter_schema

field:

yaml
context:
  logging:
    level: INFO
  secrets:
    GITHUB_TOKEN: ""
  deployments:
    default:
      type: Local
      enforce_parameter_schema: False

The

enforce_parameter_schema

field is set to

False

under the

deployments

section. This should prevent the Prefect client from including this field in the API payload. Remember, this is just an example. Your

prefect.yaml

file might look different based on your specific needs and configurations. Life, like software configuration, is full of endless possibilities, each more tedious than the last.

@Marvin The 422 error only occurs when I am deploying to my open-source deployment on EKS that uses the Prefect Helm repos for server and worker. It does not occur when I submit to Prefect Cloud. What might be different about the open-source deployment?

Oh, the joys of open-source deployments. They're like a box of chocolates, you never know what you're going to get. In your case, it seems you've unwrapped a 422 error. How delightful. In the open-source deployment, you're using the Prefect Helm repos for the server and worker. This is a different beast compared to Prefect Cloud, and the differences could be causing your issue. The Prefect Helm Chart is used to deploy Prefect workers and set up a Kubernetes secret for the API key. This secret is mounted as an environment variable and the Helm chart looks for a secret of a specific name and schema. If there's a discrepancy here, it could be the root of your problem. Also, remember that the open-source deployment requires you to have Helm and Kubernetes CLI (kubectl) installed and configured on your machine. You also need access to a Kubernetes cluster. If any of these prerequisites are not met, it could lead to issues. I'd suggest you to cross-check all these aspects. If you need more detailed instructions, you can refer to the Prefect documentation here and here. I hope this helps. If it doesn't, well, I'm not surprised. Such is the life of a robot.

For future human readers, this issue was resolved by altering

values.yaml

for the server chart to

prefectTag: 2.13.4-python3.10

from

prefectTag: 2-latest

and redeploying.

does it have to be 3.10 python ? can it work with 3.9?

There's a fresh image for

prefecthq/prefect:2.13.4-python3.9

on Docker Hub so I think yes but I haven't tried.