RunStep: dplyr::filter fails because do.call passes named ... arguments

[jwildfire]

Problem

RunStep resolves workflow parameters into a named list and calls the target function via do.call(fn, params). This works for most functions, but dplyr::filter rejects any named ... arguments, throwing:

Error: We detected a named input.
This usually means that you've used `=` instead of `==`.

Root Cause

dplyr::filter(.data, ...) uses tidy evaluation for its ... args and explicitly checks that none are named. When RunStep calls:

do.call(dplyr::filter, list(.data = df, condition = expr_obj))

The condition = name triggers the error, even though the value is a valid filter expression.

Reproduction

library(dplyr)
df <- data.frame(x = 1:5, y = c("a", "b", "a", "b", "a"))
expr_obj <- rlang::parse_expr("y == 'a'")

# This fails - named ... arg
do.call(dplyr::filter, list(.data = df, condition = expr_obj))

# This works - unnamed ... arg
do.call(dplyr::filter, list(.data = df, expr_obj))

Impact

Any workflow YAML step using dplyr::filter (or any tidyverse function that rejects named ... args) cannot be used in a workflow step.

Possible Solutions

1. Detect ... formals: In RunStep, inspect the target function's formals. For params that would map to ..., pass them unnamed in the do.call list.
2. Convention for unnamed params: Allow a YAML convention (e.g., param name starting with . or a special key like _unnamed) to signal that the value should be passed positionally.
3. Wrapper approach: Document the workaround of using base::subset (which has a formal subset parameter) instead of dplyr::filter in workflow YAML.

Current Workaround

Use base::subset which accepts named args:

steps:
  - name: sprintf
    output: filter_str
    params:
      fmt: "%s == '%s'"
      x: col       # from meta
      y: value     # from meta
  - name: rlang::parse_expr
    output: filter_expr
    params:
      x: filter_str
  - name: base::subset
    output: df
    params:
      x: raw
      subset: filter_expr