flowfile: the compiler knows every task output's declared type and the checker still says dyn — thread descriptors into env.Check
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 9
- Forks
- 0
- Avg merge
- 3h 3m
- Merged PRs (30d)
- 509
Description
Observed behavior
Reference existence is validated — an unknown step or output is a positioned unresolved-reference diagnostic — but reference types are not: checkExpressionTypes declares every referenced name dyn (pkg/flowstate/v1/flowfile/celcheck.go:66-75), so an expression made of references is judged only for unknown functions, arity, and missing overloads. A type misuse across references (${steps.fetch.status_code.startsWith("2")} where status_code is an int) passes flow validate and fails at run time — on a durable run, potentially hours in.
The types exist at compile time and stop one step short of the checker: layer 3's whole point is that TaskDef descriptors are the single source validation, dispatch, completion, and generated docs already read (docs/ARCHITECTURE.md, "layer 3 is the single source of truth for capability" — docs/reference/tasks.md renders typed outputs from them today). Input declarations carry types (#177 slice 1), wait outputs are a known shape (timed_out, payload), and a loop's results/state are structurally known.
Desired outcome
env.Check sees declared types where they are knowable — task outputs from descriptors, declared input types, wait and loop shapes — and keeps dyn where dynamism is the honest answer (an http response's json, plugin tasks without descriptors). A type misuse across typed references becomes a positioned type-mismatch-class diagnostic in flow validate and the LSP alike, since both run the same check.
Acceptance criteria
- The int-vs-string case above is a compile-time diagnostic positioned at the expression, on validate and in-editor.
- The examples corpus stays green with zero new diagnostics — genuinely dynamic outputs produce no false positives.
- No second checker and no second environment: the existing
checkExpressionTypespath grows declarations, per invariant 2. flow test's stub returns are checked against the same declared types, or the divergence is recorded (a stub that returns a shape the descriptor forbids is a test lying about production).
Adjacency
#177 (the full typed-workflows program — this slice needs none of its user-declared types, only the descriptors that already exist), #1301 (one bad expression suppressing other diagnostics — worth fixing before this raises the diagnostic count), #1377 (typed outputs on workflows would flow into the same declarations for call: results).
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in pkg/flowstate/v1/flowfile/celcheck.go:66-75 at checkExpressionTypes and trace the existing env.Check path used by flow validate and the LSP. Read the layer 3 guidance in docs/ARCHITECTURE.md and typed output behavior in docs/reference/tasks.md, then inspect the examples corpus and flow test stubs. Done means typed references diagnose mismatches while dynamic outputs remain valid.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- cli, compilers, testing-qa
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100