Distinguishing Internal vs Inputable Variables in WfSpec

[GhostArrays]

I’m proposing a clearer distinction between input variables and internal variables.

Problem:
Currently, all variables can be set at the start of a workflow execution, which creates ambiguity and potential misuse. In many cases, we want certain variables to be used only by the internal logic of the workflow — they should not be editable by the user at the time of execution.

Proposal:
Introduce a mechanism to explicitly mark variables as either:
• Internal (default): Variables meant to be used only within the workflow logic and not exposed to the user when starting a workflow.
• Inputable: Variables that can be set by the user at the time of workflow execution.

Example syntax:

wf.declareStr("name").inputable(); // This variable is user-settable at workflow start
wf.declareInt("retryCount");       // Internal-only by default

This makes the intent of each variable explicit and avoids accidental misuse. It also helps clarify the API and provides a better developer experience.

Would love to hear thoughts and feedback on this direction.

[coltmcnealy-lh]

Internal means not part of the public API of the WfSpec, which has some significances:

1. PUBLIC_VAR variables are used to determine whether a new WfSpec version is major or minor.
2. They are also used to determine what goes into the Output Topic.
3. Some users have built REST API's that treat WfSpec's like DB tables and WfRun's like rows. The PUBLIC_VAR variables are the columns.

As you observed, it doesn't have any impact on whether you can or cannot set the variable when running a WfSpec.

You can just do something like this:

WfRunVariable myVarDontSetMeAsInputPlease = wf.declareStr(...);

myVarDontSetMeAsInputPlease.assign("value that I want it to be at start");

That guards it from being overriden.