.NET: Python: [Bug]: Declarative workflow IsBlank defaults ignore inputs the caller omitted #9729

Description

In declarative workflows, a PowerFx default for an input the caller did not pass never takes effect. The simple_workflow sample sets

value: =If(IsBlank(inputs.name), "World", inputs.name)

but workflow.run({}) prints Hello, ! instead of Hello, World!.

The cause: when the inputs record has no name field, PowerFx fails to compile inputs.name (and Workflow.Inputs.name) with Name isn't valid. 'name' isn't recognized. DeclarativeWorkflowState.eval() treats that as an undefined variable and returns None for the whole expression, so the IsBlank default is never evaluated. The input only counts as blank when it is present with a blank value:

invoke_function_tool/main.py works around this with the comment "both location and unit must be provided". The existing test test_if_with_isblank avoids the case by initializing with {"name": ""}.

Separately, the simple_workflow sample discards the result of its second ("Alice") run, so it prints nothing for that run.

Reproduction

With the .NET runtime available for PowerFx, run python/samples/03-workflows/declarative/simple_workflow/main.py, or:

state = DeclarativeWorkflowState(state_store)
state.initialize({"other": 1})
state.eval('=If(IsBlank(inputs.name), "World", inputs.name)')  # None, expected "World"

Expected behavior

An input the workflow references but the caller omitted behaves as blank, the same as passing it as None, so IsBlank-based defaults apply.

Proposed fix

In DeclarativeWorkflowState.eval(), find inputs.<name> / Workflow.Inputs.<name> references in the formula. Bind any the caller did not supply to blank in the PowerFx symbols for that evaluation only, without writing them to workflow state. Other undefined names keep today's None behavior. I have a PR ready, with a regression test that fails on main.

Package Versions

agent-framework-declarative from main at 1168c00, powerfx with .NET 10.0.12 runtime.

Python Version

3.13

AI Assistance

Claude Code helped find this by running the declarative samples locally, trace it to DeclarativeWorkflowState.eval(), and draft this report. I verified the behavior locally.