Skip to main content
← Back to list
01Issue
FeatureOpenSwamp CLITeam
AssigneesNone

Relationships

#1401 Expose resource attributes in DataHandle for workflow report stepExecutions

Opened by webframp · 7/25/2026

Problem

Workflow-scope reports receive step execution data via stepExecutions[].dataHandles[], but DataHandle (defined in src/domain/models/model.ts) does not carry the resource's top-level attributes. Reports that need attribute data must call dataRepository.getContent() to read the full resource blob, deserialize it, and extract attributes manually.

PR #1963 adds an attributes field to DataArtifactRefData (the terminal view struct), proving the runtime already has access to this data at the point where step results are collected. But the same data is not threaded into the report context's DataHandle.

Proposed Solution

Add an optional attributes?: Record<string, unknown> field to DataHandle:

export interface DataHandle {
  name: string;
  specName: string;
  kind: "resource" | "file";
  dataId: DataId;
  version: number;
  size: number;
  tags: Record<string, string>;
  metadata: Omit<DataMetadata, ...>;
  attributes?: Record<string, unknown>;  // <-- new
}

Populate it from resourceAttributes (the same source PR #1963 uses for the terminal data box) when building WorkflowStepExecutionDetail in the execution service.

Use Case

Our workflow reports currently do this pattern repeatedly:

for (const step of context.stepExecutions) {
  for (const handle of step.dataHandles) {
    const raw = await repo.getContent(step.modelType, step.modelId, handle.name, handle.version);
    const data = JSON.parse(new TextDecoder().decode(raw));
    // now use data.someAttribute...
  }
}

With attributes on DataHandle, reports could inspect top-level resource fields (counts, status flags, summary scalars) without full deserialization:

for (const step of context.stepExecutions) {
  for (const handle of step.dataHandles) {
    if (handle.attributes?.totalRecords > threshold) { ... }
  }
}

This is especially valuable for workflow reports that aggregate across many steps (e.g., our morning-pulse report iterates 8+ region steps). Each getContent() call is a filesystem read + JSON parse; attributes on the handle would eliminate these for summary-level checks.

Alternatives

Reports can continue using dataRepository.getContent() for full data access. The attributes field would be an optimization for the common pattern of checking a few top-level scalars across many steps without needing the full resource body.

Lab #1400 (expose workflow inputs in report context) is a sibling request — both aim to give reports richer context without round-tripping through the data repository.

02Bog Flow
◉OPEN○TRIAGED○IN PROGRESS○SHIPPED

Open

7/25/2026, 3:59:52 PM

No activity in this phase yet.

03Sludge Pulse

Sign in to post a ripple.