Skip to content

feat: evaluate only the parameter/preset/tag closure when rendering - #221

Draft
PushTheLimit wants to merge 6 commits into
coder:mainfrom
PushTheLimit:preview-resource-closure
Draft

feat: evaluate only the parameter/preset/tag closure when rendering#221
PushTheLimit wants to merge 6 commits into
coder:mainfrom
PushTheLimit:preview-resource-closure

Conversation

@PushTheLimit

Copy link
Copy Markdown

What

Pass OptionWithResourceClosure(["coder_parameter", "coder_workspace_preset", "coder_workspace_tags"]) to the Terraform parser in Preview, so root-module resource blocks that nothing in the parameter/preset/tag closure references are skipped during evaluation.

Why

Preview evaluates the entire module graph on every call, but rendering a workspace form only needs the parameter, preset and tag blocks and what they reference. The resources a workspace would create cannot feed those blocks, so evaluating them is wasted work that dominates request latency.

Concretely this is what makes the Coder dynamic-parameters websocket slow: on a real Altana nexus-stack template, EvaluateAll is ~2s per request (prod ~4.5s), and it re-runs on every parameter change.

Result (real nexus-stack template, local)

  • EvaluateAll ~2.0s to ~0.16s (~12x)
  • Parameters, presets and tags: byte-identical (verified via a full A/B diff, including default values)

Dependency

Requires OptionWithResourceClosure from the trivy fork: coder/trivy#74. The trivy replace in go.mod is temporarily pinned to that PR's commit so this builds; it will be moved to the merged coder/trivy commit before this is taken out of draft.

Testing

  • go build ./... and the non-E2E unit suite pass.
  • End-to-end verified through coder/coder at v2.35.4: coderd/dynamicparameters tests pass against this change, with identical parameter output.

Preview evaluates the entire Terraform module graph on every call, even though
rendering a workspace form only needs coder_parameter, coder_workspace_preset
and coder_workspace_tags (and what they reference). The resources a workspace
would create cannot feed those blocks, so evaluating them is wasted work that
dominates request latency on large templates.

Pass OptionWithResourceClosure with the three target block types so the parser
drops root-module resources that nothing in that closure references. On a real
template this cuts EvaluateAll from ~2s to ~0.16s (~12x) with byte-identical
parameters, presets and tags.

Depends on the OptionWithResourceClosure addition in the trivy fork
(coder/trivy#74). The trivy replace is temporarily pinned to that PR's commit;
it will be moved to the merged coder/trivy commit before this merges.
@PushTheLimit
PushTheLimit force-pushed the preview-resource-closure branch from f3a2bc9 to adb5edc Compare August 25, 2026 21:34

@Emyrk Emyrk left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have to block on the go mod update.

I'm curious how much of a speedup this is

Comment thread go.mod Outdated
// Trivy has some issues that we're floating patches for, and will hopefully
// be upstreamed eventually.
replace github.com/aquasecurity/trivy => github.com/coder/trivy v0.0.0-20260309164037-c413f5a2f511
replace github.com/aquasecurity/trivy => github.com/PushTheLimit/trivy v0.0.0-20260825213047-3916002b18a9

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to continue to use our fork. Is this just a matter of pulling their latest?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Emyrk I state this in the PR description:

Requires OptionWithResourceClosure from the trivy fork: coder/trivy#74. The trivy replace in go.mod is temporarily pinned to that PR's commit so this builds; it will be moved to the merged coder/trivy commit before this is taken out of draft.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do the same thing in the draft of the coder/coder PR: coder/coder#28602 that will also have to do the same thing if/once these upstream deps merge.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

The PR here: https://github.com/coder/trivy/pull/74/changes

Does that only pull the change that adds OptionWithResourceClosure? Should we instead pull the latest trivy release and rebase the 2 coder commits ontop?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, https://github.com/coder/trivy/pull/74/changes is just one commit of new code I wrote, not a pull or rebase of anything from upstream trivy. It adds the OptionWithResourceClosure option plus the closure-pruning logic in evaluator.go / option.go / parser.go, with a test. Nothing comes from the upstream fossabot/trivy. It needs to be reviewed/approved/merged before we can pull that change here.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@PushTheLimit got it. So this is new change, not in Trivy.

It's worth sending upstream too, always makes it easier for us in the long run.
They have been pretty open to changes in the past.

But we can work this into our fork in the interim

@PushTheLimit

Copy link
Copy Markdown
Author

Have to block on the go mod update.

I'm curious how much of a speedup this is

For our case with a template with a large Terraform module graph it went from ~4.5s per change to ~0.4s .. including the initial page load to the create workspace form. Big improvement.

@Emyrk

Emyrk commented Aug 26, 2026

Copy link
Copy Markdown
Member

Have to block on the go mod update.
I'm curious how much of a speedup this is

For our case with a template with a large Terraform module graph it went from ~4.5s per change to ~0.4s .. including the initial page load to the create workspace form. Big improvement.

Oh that is huge and very worth it

Picks up the fix that retains resources referenced through an index
expression (count/for_each) when pruning the target closure, plus the
accompanying test coverage. Required by the closure corpus added next.
Adds a fixture whose parameters and workspace tags derive from resource
blocks through direct, local-indirected, and count-indexed references,
with an unreferenced orphan resource that pruning drops. Asserts the
parameter defaults and tag values are exactly what an unpruned
evaluation produces, so an over-aggressive prune is caught end to end
(the count-indexed case fails against the pre-fix evaluator).

Excluded from the terraform-apply e2e suite (skipe2e); the closure logic
lives in static preview evaluation, which Test_Extract covers.
…ive edges

Extends the resourceclosure fixture so each closure target type keeps a
resource independently: a preset and a workspace tag now each keep a
resource nothing else references, alongside the parameter paths. Adds a
for_each index reference and a transitive resource->resource chain. The
for_each and count-index cases fail against the pre-fix evaluator and
pass with the indexed-reference fix; the full existing corpus still
passes with the closure enabled.
@PushTheLimit

PushTheLimit commented Sep 2, 2026

Copy link
Copy Markdown
Author

@Emyrk added the coverage you were after 👍 New resourceclosure fixture in Test_Extract exercises each closure target independently: a parameter, a preset, and a workspace tag each keep a resource nothing else references, across direct, local, count-index, for_each-index, and transitive resource->resource refs, plus an orphan that gets pruned. The for_each/count cases fail against the pre-fix evaluator and pass with your indexed-ref fix, so they pin down exactly the over-prune you flagged. And the whole existing Test_Extract corpus still passes with the closure on.

The go.mod replace here is on the trivy branch with the fix for now; I'll swap it to the merged coder/trivy commit before this comes out of draft.

@Emyrk

Emyrk commented Sep 2, 2026

Copy link
Copy Markdown
Member

@PushTheLimit awesome 👍

I'm going to kick an agent to see if it can think of any other test vectors to throw in.
These tests are going to be the confidence to merge in

Fills gaps in the corpus with thorough parameter/tag assertions for
fixtures that had no Test_Extract case:

- countsub: count-guarded parameter and a tag driven by a submodule output
- http: a tag from an http data source that is unknown without plan data
- notstringtag: non-string tag keys and values coerced to strings
- wordle: seven parameters that default to the empty string

Assertion-only; no changes to preview behavior.
Asserts each parameter's value, default and form type, including the four
whose form_type is resolved from a sibling *_format dropdown's value
(single->radio, number->input, boolean->radio, list->multi-select). The
count-guarded satisfaction parameter is correctly absent because like_it
defaults false.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants