Bug: inline workflows in config.yaml decode differently from workflows.path and fail during workflow clone

[michaelw]

Summary

Inline workflows: definitions in the main config.yaml do not behave the same as loading the same workflow DSL from a standalone workflows.yaml referenced via workflows.path.

In practice, the inline definitions appear to load far enough to be selected, but the workflow later fails during clone / resume / execution. Moving the exact same workflow YAML into a separate workflow file and loading it via workflows.path succeeds.

This seems unrelated to the new request sudo flow itself; it looks like a config decoding / workflow unmarshalling discrepancy between inline config and standalone workflow loading.

Expected behavior

The same workflow DSL should have identical semantics whether it is:

• declared inline under workflows: in the main config.yaml
• loaded from a standalone workflow file via workflows.path

Actual behavior

With inline workflow definitions in config.yaml, the workflow later fails during clone / resume / execution.

Observed errors:

Failed to unmarshal workflow for cloning - unknown task type for key ''. Available types: [listen wait try call_openapi call_asyncapi emit fork call_http call_grpc thand switch do for run set call raise]

and then:

failed to hydrate resumed workflow task: failed to load workflow

The same workflow works when moved into a dedicated workflows.yaml and loaded via workflows.path.

Reproduction

Inline config.yaml variant that fails

version: "1.0"

providers:
  local-elevation:
    name: Local Elevation
    provider: local
    enabled: true

roles:
  local_sudo:
    name: Local Sudo
    workflows:
      - local_sudo_timed_elevation
    permissions:
      allow:
        - operations:
            - local:sudo:*
    providers:
      - local-elevation
    enabled: true

workflows:
  local_sudo_timed_elevation:
    name: "Local Sudo Timed Elevation"
    authentication: default
    enabled: true
    workflow:
      document:
        dsl: "1.0.0-alpha5"
        namespace: "thand"
        name: "local-sudo-timed-elevation"
        version: "1.0.0"
      do:
        - validate:
            thand: validate
            with:
              validator: static
            then: authorize
        - authorize:
            thand: authorize
            with:
              revocation: revoke
            then: monitor
        - monitor:
            thand: monitor
            with:
              monitor: basic
              threshold: 100
            then: revoke
        - revoke:
            thand: revoke
            then: end

Equivalent standalone workflows.yaml that succeeds

Main config:

version: "1.0"

providers:
  local-elevation:
    name: Local Elevation
    provider: local
    enabled: true

roles:
  local_sudo:
    name: Local Sudo
    workflows:
      - local_sudo_timed_elevation
    permissions:
      allow:
        - operations:
            - local:sudo:*
    providers:
      - local-elevation
    enabled: true

workflows:
  path: /path/to/workflows.yaml

Referenced workflow file:

version: "1.0"
workflows:
  local_sudo_timed_elevation:
    name: "Local Sudo Timed Elevation"
    authentication: default
    enabled: true
    workflow:
      document:
        dsl: "1.0.0-alpha5"
        namespace: "thand"
        name: "local-sudo-timed-elevation"
        version: "1.0.0"
      do:
        - validate:
            thand: validate
            with:
              validator: static
            then: authorize
        - authorize:
            thand: authorize
            with:
              revocation: revoke
            then: monitor
        - monitor:
            thand: monitor
            with:
              monitor: basic
              threshold: 100
            then: revoke
        - revoke:
            thand: revoke
            then: end

Notes

My current guess is that inline workflows: go through a different decode/unmarshal path than file-loaded workflows, and the nested task structure is not surviving that path in the same shape.

Workaround

Move custom workflow DSL into a standalone workflow file and load it via workflows.path instead of declaring the workflow inline in config.yaml.