Problem

Two gaps break lineage tracking, whose goal is to capture everything that distinguishes one task execution from another (ideally everything that feeds the task hash) so differences can be diffed from the lineage records.

1. Stub-run produces no task lineage records. Running with -stub-run writes only the WorkflowRun record; every TaskRun, TaskOutput and FileOutput record is silently lost.

2. Output eval commands are absent from the lineage record. Output eval(...) commands contribute to the task hash, but the command strings are not stored in the TaskRun lineage record. Two executions that differ only in an eval command get different hashes but indistinguishable lineage records.

Root cause

Stub-run

LinObserver.onTaskComplete does fire for stub tasks, but storeTaskRun throws and the exception is swallowed at debug level by Session.notifyEvent:

groovy.lang.MissingPropertyException: No such property: source for class: nextflow.script.dsl.ProcessDslV1
    at nextflow.processor.TaskRun.getStubSource(TaskRun.groovy:1023)
    at nextflow.lineage.LinObserver.storeTaskRun(LinObserver.groovy:258)

storeTaskRun computes the code checksum from task.stubSource when session.stubRun is set. getStubSource() accessed config?.getStubBlock()?.source. getStubBlock() returns a TaskClosure (a Groovy Closure); accessing .source as a property routes through Closure.getProperty, which resolves the name against the closure's delegate — the ProcessDslV1 script object — which has no source property. resolveStub is unaffected because it calls block.getSource() as a method. Because WorkflowRun is written in onFlowBegin (before any task completes), it survives while everything from onTaskComplete is lost.

Eval outputs

A normal run already records the eval result value in TaskOutput ({"type":"eval","name":"nxf_out_eval_1","value":"hello"}), but the eval command (echo hello) — the part that feeds the task hash via TaskHasher.computeEvalOutputCommands — is not stored anywhere in the TaskRun record. Moreover the hash keys on both the eval output name and its command, so the name must be recorded too: otherwise two executions that differ only by eval output name get different hashes but indistinguishable lineage records.

Solution

• TaskRun.getStubSource(): call getStubBlock()?.getSource() (method) instead of ?.source (property).
• Lineage TaskRun model: add a Map<String,String> eval field (output name → command, in output-declaration order) populated in LinObserver.storeTaskRun from task.getOutputEvals(); null when the task has no eval outputs. Both the name and the command feed the task hash (TaskHasher.computeEvalOutputCommands), so both are recorded. Declaration order is preserved, which is deterministic across executions of the same script, so eval records remain directly comparable.

Backward compatibility

The lineage models are (de)serialized by Gson via name-based field reflection, not by positional constructor. Records written before this change have no eval field and deserialize with eval == null; new records add it. The field is appended last, matching the convention for additive fields (e.g. labels in TaskOutput/FileOutput). v1beta1 is a beta model; an additive optional field does not warrant a version bump.

Tests

• TaskRunTest: getStubSource() regression (via a real TaskClosure whose owner has no source property — verified to fail on the old .source and pass on .getSource()) plus a null-stub-block case.
• LinObserverTest: eval output names and commands are recorded as a map; null when there are no evals.
• tests/lineage-stub-eval.nf + .checks: end-to-end under both -stub-run and normal mode, asserting the TaskRun record exists, carries "eval":{"nxf_out_eval_N":"echo hello"}, and records the correct source code (stub vs. main script).

🤖 Generated with Claude Code