data.latest() in workflow step inputs resolved at workflow start, not at step execution time

[stack72]

Description

When a workflow uses data.latest() expressions in step inputs, these expressions are resolved at workflow start time rather than when the step actually executes. This means steps in later jobs receive stale data from previous runs instead of fresh data written by earlier jobs in the same workflow run.

Steps to Reproduce

1. Create a workflow with two jobs:
   • Job 1 (create): Creates a resource (writes new data via create method)
   • Job 2 (get): Gets the resource using data.latest() to resolve the identifier — depends on Job 1 succeeded
2. Run the workflow once — succeeds (no prior data, expressions deferred to runtime)
3. Run the workflow again — Job 1 succeeds, but Job 2 fails because data.latest() resolved to the OLD identifier from the previous run

Example

jobs:
  - name: create-resources
    steps:
      - name: create-vpc
        task:
          type: model_method
          modelIdOrName: test-vpc
          methodName: create

  - name: get-resources
    dependsOn:
      - job: create-resources
        condition:
          type: succeeded
    steps:
      - name: get-vpc
        task:
          type: model_method
          modelIdOrName: test-vpc
          methodName: get
          inputs:
            identifier: ${{ data.latest("test-vpc", "swamp_aws_crud_test_vpc").attributes.VpcId }}

Run 1 (no prior data): data.latest() can't resolve at start → deferred to runtime → resolves to newly created vpc-0652aafe3207ce5e6 → PASS

Run 2 (stale data from run 1 exists): data.latest() resolves at start to vpc-0652aafe3207ce5e6 (old, now deleted) → create writes new vpc-0f2acbed8e5689ccb → get step uses pre-resolved old ID → FAIL:

Resource 'vpc-0652aafe3207ce5e6' was deleted at 2026-03-07T22:56:22.253Z — run a 'create' method to re-create it first

Evidence

• swamp data get test-vpc swamp_aws_crud_test_vpc --json confirms version 6 has the correct new VpcId vpc-0f2acbed8e5689ccb
• But the get step received the old VpcId vpc-0652aafe3207ce5e6
• get-key-pair succeeded because its identifier (KeyName: swamp_aws_crud_test_kp) is a constant that doesn't change between runs — masking the bug for that step

Expected Behavior

data.latest() expressions in step inputs should be lazily evaluated when the step executes (after dependent jobs have completed and written new data), not eagerly at workflow start time.

Impact

Any workflow that creates resources and then references them via data.latest() in later jobs will fail on second and subsequent runs. This makes CRUD test workflows non-repeatable without manually clearing data between runs.

Summary

This bug is in the workflow runtime's expression evaluation phase. data.latest() expressions in step inputs need to be deferred until step execution time rather than resolved during the pre-run evaluation pass. The fix would involve treating data.latest() (and potentially other data-referencing expressions) as runtime-resolved rather than evaluate-time-resolved when they appear in step inputs.

Found during AWS EC2 CRUD testing in /testing/aws/.

[stack72]

Root Cause Analysis

After investigating the code and the actual workflow run data from testing/aws/, the bug is not about data.latest() expressions being evaluated at the wrong time. The expression deferral logic works correctly — the evaluated workflow at .swamp/workflows-evaluated/ confirms the ${{ data.latest(...) }} expressions are properly left as raw strings for step-execution-time evaluation.

The actual bug is in the CRUD lifecycle deleted-resource check in src/domain/models/method_execution_service.ts lines 267-300:

// Fast-fail: reject read/update on deleted resources
if (methodKind === "read" || methodKind === "update") {
  const resources = modelDef.resources ?? {};
  if (Object.keys(resources).length > 0) {
    const existingData = await context.dataRepository.findAllForModel(
      context.modelType,
      context.modelId,
    );
    for (const data of existingData) {
      if (data.isDeleted) {
        throw new UserError(
          `Resource '${data.name}' was deleted at ${deletedAt} — run a 'create' method to re-create it first`,
        );
      }
    }
  }
}

Why it fails

findAllForModel() returns all data entries for the model — including historical data under old data names. When the check iterates, it finds the first deleted entry and throws immediately, even if the current working data is active.

At the time the get step ran (23:22:45), the VPC model had:

Data Name	Latest Version	Lifecycle	Created
swamp_aws_crud_test_vpc_v2	v1	active ✅	23:22:26
swamp_aws_crud_test_vpc	v7	deleted ❌	23:17:03
vpc-0652aafe3207ce5e6	v2	deleted ❌	22:56:22
vpc-0f2acbed8e5689ccb	v2	deleted ❌	earlier

The lifecycle check hit vpc-0652aafe3207ce5e6 (old historical deleted data), threw, and the get method never executed. The data.latest() expression would have resolved correctly — but the method was killed before it ran.

Why this matches the symptoms

• Run 1 succeeds: No prior data exists, so findAllForModel() returns nothing (or only active data). The lifecycle check passes.
• Run 2 fails: Old deleted data from run 1 still exists on disk. findAllForModel() finds it, the check throws, and the error message references the old data name/ID — making it look like the expression resolved to stale data.
• Error messages reference old names: "Resource 'swamp_aws_crud_test_kp' was deleted" — that's data.name from the old deleted entry, not the identifier input.

Fix

The lifecycle check needs to be scoped. Instead of rejecting the operation if any data entry for the model was ever deleted, it should only check data that's relevant to the current operation — e.g., data matching the current resource spec or the model's configured data name (globalArguments.name).

[stack72]

Introducing Change

PR #640 (fix: track resource deletion in local data model) introduced this regression. The fast-fail lifecycle check was designed for a simple single-data-name lifecycle (create → delete → get fails → create again works), but doesn't account for models with multiple data entries — where old deleted data coexists with new active data under a different name.

The E2E test in that PR only verified the single-name lifecycle, never the multi-name scenario that occurs in repeated workflow runs with changing globalArguments.name.