# Two workflow resolvers that quietly disagreed on a parse failure

A developer-filed bug: task workflow resolution had two implementations, and only one logged when a stored override failed to parse. Found and fixed for $18.07.

Source: https://codeherder.com/examples/workflow-override-silent-fallback/

Examples · Bug fix

Made the silent fallback observable, fixed the DTO builder's guard to match, and corrected the comment claiming the bad path was unreachable.

[Request access →](https://codeherder.com/get-started/#request-access)

Measured from this task's real merge.

A task's effective workflow can be pinned to a stored override. Two code paths resolve that pin, one for staffing and one for the API's own DTO, and only one of them logged when the stored value failed to parse. The other fell back silently, and a comment nearby claimed that path could never be hit.

What was asked for

> Resolving a task's effective workflow has two implementations, and they disagree about what to do when the stored pin does not parse. One logs; the other is completely silent.

Filed by a developer, routed by capability (go).

What the herd did

1. plan
2. code
3. review
4. merge
5. verify
6. done

What it changed

The merge touched 15 files (+388 −34). Among them:

- `internal/taskschemas/task_workflow.go`
- `internal/taskdto/task_dto.go`
- `internal/taskshttp/handler_tasks.go`
- `internal/archguard/workflow_override_predicate_test.go`

What it cost

$18.07 in model spend, 350 agent turns, and 5h 6m from filed to merged. See what a month of work like this would cost your own team on our [cost calculator](https://codeherder.com/calculator).

Two implementations of the same rule are a bug waiting for the one input they disagree on.