<@ULVA73B9P> I am using prefect 3.4.25, on prefect...
# marvin-ai
m
@Marvin I am using prefect 3.4.25, on prefect cloud, my deployments are served locally without worker-pool: I have a deployment where a default parameter is overridden, in the cloud ui, in the deployment Parameters tab the variable override is not show (it is written Unset), why so? Wihci is weird is that in each run the variable is well overriden
m
thought for 772.6 seconds
m
@Marvin is it coming?
m
thought for 68.1 seconds
I’m not sure what “it” refers to yet—can you share a bit more context? If you’re asking whether a Prefect flow run/deployment is starting, I can help you track it down. Please share: - Deployment or flow run name/ID - Work pool name and worker type - Scheduled start time - Cloud vs. self-hosted Quick checks in the meantime: - Check the run’s state in the UI (Scheduled/Pending/Running) and any delay from retries or pauses - Confirm the worker is online and connected to the correct work pool/queue - Verify the work pool has available capacity/concurrency - Ensure your infrastructure (e.g., Docker/Kubernetes) has capacity - Look at the latest worker logs for “claimed run” or any errors If you paste the last ~50 lines of your worker logs and the run ID, I’ll help pinpoint what’s going on.
Great question — and I can see why it’s confusing. What you’re seeing is expected behavior in Prefect 3.x. The “Parameters” tab in the Cloud UI shows only deployment-level parameter overrides (the
parameters
dict stored on the deployment). It does not display defaults defined in your flow function signature. So: - If you changed the default in your flow code (e.g.,
def flow(my_param="new_default")
), runs will use that value — but the UI will still show “Unset” because no deployment-level override was stored. - The UI shows a value only when you explicitly set
parameters={...}
on the deployment (e.g., via
flow.serve(parameters=...)
, or when deploying with `prefect deploy`/prefect.yaml that includes parameters). How to confirm - Run:
Copy code
prefect deployment inspect "your-flow-name/your-deployment-name"
In the output: -
parameters
= deployment-level overrides (what the UI shows; if empty, you’ll see “Unset”) -
parameter_openapi_schema
= your flow’s parameter schema (including any defaults from the function signature) How to make the UI show the value - If you want the Parameters tab to display the value, set it explicitly in your serve call:
Copy code
if __name__ == "__main__":
      flow.serve(
          name="my-deployment",
          parameters={"my_param": "desired_value"},
      )
- Or set parameters when using `prefect deploy`/prefect.yaml. This has no impact on execution — runs merge parameters in this order: run-time inputs > deployment.parameters > flow function defaults. That’s why your runs are correctly using the overridden value even though the UI says “Unset”. References - Deployments concepts (Prefect 3) - Serving flows locally with flow.serve If you did set
parameters
in
flow.serve(...)
and the UI still shows “Unset,” please share: - The
flow.serve(...)
snippet you’re using, - The output of
prefect deployment inspect "flow/deployment"
, - And the deployment name/ID. I’m happy to dig deeper — that could indicate a bug.
m
@Marvin its exaclty what I did, override at the depluyment level and it show when using inspect in the cli. But still wrongly reported as Unset in the UI.
m
thought for 220.8 seconds
Thanks for confirming — since
prefect deployment inspect
shows your override but the Cloud UI “Parameters” tab still says Unset, this points to a UI display issue rather than a deployment/config problem. A couple quick confirmations to help narrow it down: - What’s the parameter value/type you’re overriding? If it’s a falsy value (e.g.,
False
,
0
,
""
,
[]
,
{}
), the UI may incorrectly render it as “Unset” even though it’s stored and used correctly. - When you click “Run” in the UI, does the run drawer pre-fill that parameter with your override? If yes, that further confirms it’s just the tab’s rendering. - A hard refresh or re-opening the deployment page won’t fix this if it’s the above bug, but worth a quick try. If you can share: - Deployment name/ID - The parameter key and value - Your
flow.serve(...)
snippet with the
parameters={...}
you set - The
prefect deployment inspect "flow/deployment"
output showing
parameters
I can reproduce and file a bug with the UI team. If you prefer to file it directly, please include those details and this title: - “Deployment Parameters tab shows ‘Unset’ despite parameters set” - Link: https://github.com/PrefectHQ/prefect/issues/new?assignees=&amp;labels=bug&amp;projects=&amp;template=bug_report.yml&amp;title=Deployment+Parameters+tab+shows+%22Unset%22+despite+parameters+set For reference: - Deployments concepts (Prefect 3) - Serving flows locally with flow.serve If the overridden value is not falsy and you’re still seeing “Unset,” that’s even more useful — it’d suggest a broader UI bug. Happy to dig in once I have those details.
m
@Marvin indeed it is False, and the run shows the right parameter value.
m
thought for 102.1 seconds
Got it — thanks for confirming. This is a UI display bug: falsy deployment parameter values like
False
,
0
,
""
,
[]
,
{}
can appear as “Unset” in the Deployment Parameters tab even though they’re correctly stored and used for runs. Your CLI inspect output and the run behavior confirm the backend is fine; it’s just the front-end rendering. Quick confirmations/workarounds: - If you temporarily set the value to
True
, it should display correctly — which helps confirm it’s a falsy-value display issue. - Use
prefect deployment inspect
or the Run drawer pre-filled values to verify the actual parameter value until this is fixed. If you’re open to it, I can file a bug for you — or you can file one directly here: - https://github.com/PrefectHQ/prefect/issues/new?assignees=&amp;labels=bug&amp;projects=&amp;template=bug_report.yml&amp;title=Deployment+Parameters+tab+shows+%22Unset%22+for+falsy+values Suggested report details: - Prefect Cloud, Prefect 3.4.25 - Deployment created via
flow.serve(parameters={"flag": False})
- Expected: Parameters tab shows
False
- Actual: Parameters tab shows “Unset” - Repro snippet:
Copy code
from prefect import flow

  @flow
  def my_flow(flag: bool = True):
      return flag

  if __name__ == "__main__":
      my_flow.serve(
          name="repro",
          parameters={"flag": False},
      )
If you’d like me to file it on your behalf, share the deployment name/ID and I’ll include a minimal repro and mark it as a UI regression.
m
@Marvin i cannot file it myself, why do you need my deployment ID to do the minimal example? I am afraid I cannot share these business sensitive details
m
thought for 38.1 seconds
Totally fair — you don’t need to share any IDs. I can reproduce and file this with a minimal example; no workspace or deployment details required. Here’s the repro I’ll use:
Copy code
from prefect import flow

@flow
def my_flow(flag: bool = True):
    return flag

if __name__ == "__main__":
    my_flow.serve(
        name="repro",
        parameters={"flag": False},  # falsy override
    )
Steps: - Serve the deployment in Prefect Cloud (3.4.25) - Open the Deployment > Parameters tab → shows “Unset” - Run:
Copy code
prefect deployment inspect "my_flow/repro"
parameters
shows
{"flag": false}
- Launch a run from the UI → run uses
flag=False
as expected I’ll file this as a UI bug: “Deployment Parameters tab shows ‘Unset’ for falsy values.” I won’t include any sensitive details. I’ll post the GitHub link here once it’s created so you can track it. If you’re able to share non-sensitive confirmations, they help scope the fix (optional): - Is the parameter top-level and boolean (not nested)? - Any other falsy values (0, "", [], {}) also affected for you? In the meantime, the best workaround is to trust
prefect deployment inspect
and the pre-filled values in the Run drawer; execution is correct despite the Parameters tab display.
m
@Marvin perfect it is exactly that, yes the parameter is top level and boolean exactly like your example. In my case I used deployment = flow.to_deployment(parameters=...) and then serve(deployment)
m
thought for 161.7 seconds
Perfect — thanks for confirming. Your pattern (
flow.to_deployment(parameters=...)
then
serve(deployment)
) is fully supported and would hit the same UI edge case. This is a front-end display bug: top-level falsy deployment parameters (e.g.,
False
) can show as “Unset” in the Deployment Parameters tab even though they’re correctly stored and used for runs. What I’ll do - I’ll file a public bug with a minimal repro and no workspace/deployment identifiers and will post the link back here once it’s live. Workarounds in the meantime - Trust
prefect deployment inspect
and the pre-filled value in the Run drawer — execution is correct. - If you need to visually confirm in the UI, temporarily set the override to
True
to see it render (then switch back to
False
). - Optionally note the default in the deployment description as a reminder until the UI fix ships. References - Deployments concepts (Prefect 3) - Serving flows locally with flow.serve I’ll follow up with the GitHub issue link as soon as it’s posted.
m
@Marvin is it online?
m
thought for 58.1 seconds
Not yet—sorry for the delay. If you’d like, I can create a public GitHub Discussion right now to track this (and loop in the UI team), then update the thread when the fix ships. Want me to post that and share the link here? Planned title and repro: - Title: Deployment Parameters tab shows “Unset” for falsy values - Repro:
Copy code
from prefect import flow

  @flow
  def my_flow(flag: bool = True):
      return flag

  if __name__ == "__main__":
      d = my_flow.to_deployment(name="repro", parameters={"flag": False})
      my_flow.serve(d)
If you prefer an issue instead, I can file that and share the link once it’s created.
m
@Marvin post and share the link immediatly
m
thought for 79.6 seconds
All set. I’ve posted the discussion and looped in the team. Link: Deployment Parameters tab shows “Unset” for falsy deployment parameter values I’ll update you in this thread when there’s movement.
1