Feat/make auto emit events configurable from argo UI

[tfurmston]

This PR is a re-opening of this PR, which was merged and then reverted.

The reason for the original PR being reverted can be found here. Essentially, because of the following:

• introducing a new always-present parameter to flows on argo that will be confusing to users
• adding argo-specific references to parameters.py is undesirable

Previous PR Description

It adds a parameter to Metaflow Argo Workflow templates that allows users to toggle whether to emit event information to Argo Events when submitting a workflow from the Argo Workflow UI.

This feature was discussed on the Metaflow Outerbounds Slack workspace here.

[tfurmston]

Hey @saikonen

I've reopened the PR here.

I haven't had time to look into this thoroughly yet, but am going to explore some mechanisms of defining parameters that can override CLI options where applicable.
Some kind of way to configure that "this is a CLI option I want to expose in Argo as well" is needed, but not all options can be lifted anyway as some are deploy-time only.

For my understanding, when you are talking about CLI option you are talking about the CLI options in the Argo Workflows plugin, right? So the idea would be to allow certain CLI options in that plugin to become parameters in the workflow somehow?

[tfurmston]

@saikonen How about we add a Boolean flag to the Argo Workflow CLI that when set adds this particular option as a parameter to the workflow?

If the flag is set and the there is a nameclash with an existing parameter in the workflow, which I guess would be very unlikely anyway, we would just fail the workflow creation. If someone wanted this option set, they would have to update the parameter name in the workflow.

Would be much less intrusive to the main codebase than the original approach.

What do you think?

[greptile-apps]

Greptile Summary

This PR re-introduces the feature from PR #2770 (merged then reverted) that exposes auto_emit_argo_events as a runtime-configurable Argo Workflow parameter, allowing users to toggle Argo Events emission from the Argo UI without re-deploying. The mechanism works by replacing the previously baked-in --with=argo_workflows_internal:auto-emit-argo-events=<0|1> CLI argument with an Argo template substitution {{workflow.parameters.auto_emit_argo_events}}, backed by a new workflow-level Arguments parameter.

However, the PR description itself acknowledges the two root causes of the revert, and the current implementation does not appear to resolve either of them:

• Always-present parameter (UI confusion): The auto_emit_argo_events parameter block (lines 968–974 in argo_workflows.py) is appended unconditionally to every Argo workflow's .arguments(). It will appear in the Argo UI for all deployed flows — including those with no Argo Events integration, where auto_emit_argo_events was False at deploy time. Guarding the block behind a condition (e.g., only when self.auto_emit_argo_events is True or self.triggers is non-empty) would reduce the noise for non-events users.

• Argo-specific name in parameters.py: Adding "auto-emit-argo-events" to the global reserved-parameter list in metaflow/parameters.py continues to couple a general-purpose Metaflow module to an Argo-specific concept. A cleaner approach would be to enforce the reservation within the Argo plugin (e.g., in a _reserved_parameter_names hook on ArgoWorkflows or its CLI).

• Integer default value vs. string UI input: The parameter default is stored as the integer 1 or 0 (.value(1 if self.auto_emit_argo_events else 0)), while the description does not tell users which input values are accepted. Because the decorator evaluates self.attributes["auto-emit-argo-events"] as a Python truthiness check, strings like "false", "no", or "disabled" entered in the Argo UI would evaluate to True — silently keeping event emission enabled against the user's intent. Documenting accepted values (0 to disable, 1 to enable) in the description, and/or constraining the Argo parameter with an enum or pattern, would prevent this class of mistake.

Confidence Score: 1/5

• Not safe to merge — the two explicit reasons cited for reverting the previous iteration (PR Feat - Make auto emission of events configurable from argo UI #2770) are still present in this implementation.
• The PR description acknowledges the revert reasons but the diff makes the same structural choices: the Argo-specific reserved name is still added to the shared parameters.py, and the auto_emit_argo_events parameter is still unconditionally appended to every workflow's arguments. Neither issue has been addressed differently from the reverted PR, so the same root concerns apply.
• Both changed files need attention: metaflow/parameters.py for the Argo-specific coupling, and metaflow/plugins/argo/argo_workflows.py for the unconditional parameter addition and missing input validation in the description.

Important Files Changed

Filename	Overview
metaflow/parameters.py	Adds "auto-emit-argo-events" to the global reserved parameter list — the same Argo-specific coupling that was cited as one of the two explicit reasons for reverting PR #2770.
metaflow/plugins/argo/argo_workflows.py	Replaces the baked-in deploy-time auto-emit-argo-events value with an Argo workflow parameter substitution, and unconditionally adds the parameter to every workflow's arguments — the same root issue (always-present confusing parameter) that caused the revert of PR #2770.

_{Reviews (3): Last reviewed commit: "Merge branch 'master' into feat/make_aut..." | Re-trigger Greptile}

[greptile-apps]

Parameter always added, regardless of Argo Events usage

The auto_emit_argo_events parameter is appended unconditionally to every Argo workflow's .arguments(), so it will appear in the Argo UI for all deployed flows — even those that have no Argo Events integration and where auto_emit_argo_events was False at deployment time.

This is the same root issue that caused the previous incarnation of this change (PR #2770) to be reverted: it "introduc[es] a new always-present parameter to flows on Argo that will be confusing to users".

If the intent is to expose the toggle only for flows that actually use Argo Events (or that were deployed with auto_emit_argo_events=True), the block should be guarded:

# Only expose the toggle when the workflow was deployed with Argo Events awareness
+ ([
+     Parameter("auto_emit_argo_events")
+     .value(1 if self.auto_emit_argo_events else 0)
+     .description(
+         "Toggle used to control emission of events to Argo Events."
+     )
+ ] if self.triggers or self.auto_emit_argo_events else [])

Without this guard, every Metaflow user running on Argo will see an unfamiliar auto_emit_argo_events parameter that is irrelevant to their workflow, which re-introduces the exact problem that led to the prior revert.

[greptile-apps]

Argo-specific reserved name leaks into general parameters.py

Adding "auto-emit-argo-events" (and implicitly "auto_emit_argo_events" via the hyphen-to-underscore conversion on line 417) to the global reserved parameter list in parameters.py couples a general-purpose Metaflow module to an Argo Workflows-specific concept.

This was one of the two explicit reasons cited for reverting PR #2770: "adding argo-specific references to parameters.py is undesirable".

Consider keeping this reservation within the Argo plugin itself — for example, by overriding a _reserved_parameter_names hook in ArgoWorkflows (or its CLI) rather than hard-coding Argo-specific names in the shared parameters.py.

[tfurmston]

Greptile Summary

This PR re-introduces a change (originally in PR #2770, which was merged and then reverted) that makes the auto-emit-argo-events toggle configurable at Argo workflow submission time by exposing it as an Argo workflow-level parameter (auto_emit_argo_events). The CLI flag previously baked in the deployment-time boolean is replaced with an Argo template expression {{workflow.parameters.auto_emit_argo_events}}, letting users override it from the Argo UI.

However, the PR does not appear to have addressed either of the two issues cited in the original revert:

* **Always-present parameter**: `auto_emit_argo_events` is appended unconditionally to the workflow arguments of every Argo flow, including those that have no Argo Events integration. This will surface a confusing, irrelevant parameter in the Argo UI for the majority of users.

* **Argo-specific coupling in `parameters.py`**: Adding `"auto-emit-argo-events"` to the global reserved parameter list in `parameters.py` introduces an Argo-specific concept into a general-purpose module, which is undesirable from an architectural standpoint.

Both of these issues were explicitly listed as the reasons for the prior revert, and neither seems to be addressed in this re-submission.

Confidence Score: 2/5

* This PR re-introduces changes that were previously reverted without addressing the underlying architectural concerns that triggered the revert.

* The two issues that caused the original PR to be reverted — unconditional exposure of an Argo-specific parameter for all workflows, and coupling `parameters.py` to Argo — are both still present in this re-submission. The functional change itself is straightforward and likely correct at runtime, but the design concerns are significant enough to warrant addressing before merging.

* `metaflow/parameters.py` (Argo-specific reserved name in a general module) and `metaflow/plugins/argo/argo_workflows.py` (unconditional addition of the `auto_emit_argo_events` parameter to all workflows).

Important Files Changed

Filename Overview
metaflow/plugins/argo/argo_workflows.py Replaces the hard-coded auto-emit-argo-events CLI flag with an Argo template expression {{workflow.parameters.auto_emit_argo_events}} and adds a corresponding workflow-level parameter so the value can be overridden from the Argo UI. The parameter is added unconditionally to all workflows, reintroducing the UX concern that caused the previous PR to be reverted.
metaflow/parameters.py Adds "auto-emit-argo-events" to the global reserved parameter name list, coupling a general-purpose module to an Argo-specific concept — the same architectural concern that caused the original PR to be reverted.

Last reviewed commit: 5ea7c67

This is true, but at present the PR has been reopened as-is in order to discuss alternatives. As such, it is not suggested that this PR has addressed those issues, which I agree are valid points. Once we reach a consensus I will be happy to make the changes to address these points.

[greptile-apps]

Parameter description does not document valid values

The description "Toggle used to control emission of events to Argo Events." doesn't tell users which values are accepted. The decorator parser in decorators.py (extract_args_kwargs_from_decorator_spec) first attempts json.loads, then int, then float, falling back to a raw string. Most common inputs ("0", "1", "true", "false") parse correctly to falsy/truthy values, but a user who enters "no", "off", or "disabled" will end up with a non-empty string that evaluates as truthy — silently keeping event emission enabled despite their intent.

Updating the description to explicitly state the accepted values would prevent this confusion:

Suggested change

	.description(
	"Toggle used to control emission of events to Argo Events."
	)
	.description(
	"Toggle used to control emission of events to Argo Events. Set to 1 to enable, 0 to disable."
	)