Use of text/template is causing DCE (dead code elimination) to be disabled

[kruskall]

Short description

text/template usage is causing DCE (dead code elimination) to be disabled for opa and any application depending on it.

Use of text/template outside of tests should be avoided or replaced with another templating library

imports:

opa/v1/topdown/template.go

Line 5 in b86ad9f

"text/template"

opa/internal/gojsonschema/errors.go

Line 7 in b86ad9f

"text/template"

opa/internal/gojsonschema/schema.go

Line 34 in b86ad9f

"text/template"

Steps To Reproduce

• build opa or add a dependency on the opa go package
• observe large binary with DCE disabled

Expected behavior

Small binaries with DCE enabled

Additional context

See golang/go#72895

[anderseknert]

Thanks for raising this! This is the first time I hear about it, but that's certainly unfortunate. I don't think the size of OPA's own binary is likely to be a problem for most users (~45 MB using the -static version without Wasmtime bundled), but I can certainly see how it could be for downstream projects if it eliminates DCE entirely. Which seems like an issue that at least from my naive understanding would need to be fixed in Go.

Also, thanks for pointing out the locations where this import exists in OPA. As we have a built-in function that pretty much does nothing but to mirror the Go function, we can't realistically have it removed without breaking existing deployments. So "replaced with another templating library" sounds like it would be the best option here... but I doubt there is one that is 100% compatible in behavior but without relying on the same APIs that have DCE disabled?

Only other option I can think of right now would be something like adding a build tag for this specifically, allowing downstream dependencies to opt-out of including that built-in function in their build. The gojsonschema lib is AFAIK a vendored dependency, and while touching that code is awkward, it looks like it could perhaps be done without major surgery. But I've only really spent a few minutes thinking about this, so it could very well be that there are issues I've not yet considered.

[stale]

This issue has been automatically marked as inactive because it has not had any activity in the last 30 days. Although currently inactive, the issue could still be considered and actively worked on in the future. More details about the use-case this issue attempts to address, the value provided by completing it or possible solutions to resolve it would help to prioritize the issue.

[rchildress87]

I am experiencing a negative impact due to this reported issue. Combined with my usage of the AWS SDK for Go v2, my binary is compiling to ~775mb when linked with OPA, about 600mb larger than it should be. My estimates suggest ~75% of the bloat is from dead code.

[srenatus]

Can you somehow verify that it's due to text/template...? 🤔

[rchildress87]

Yes, I believe I can. Thanks for the reply. I'll see what I can put together. Sent from Proton Mail for Android.

…

-------- Original Message --------

On Wednesday, 07/01/26 at 12:12 Stephan Renatus ***@***.***> wrote: **srenatus** left a comment (open-policy-agent/opa#7903) Can you somehow verify that it's due to text/template...? 🤔 — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you commented.Message ID: ***@***.***>

[rchildress87]

@srenatus

Full transparency: I researched this issue and cause with the help of Opus 4.8 and Sonnet 5. I don't believe that should discredit the report but please forgive any related weirdness.

I ran into (what I believe) is the problem while trying to slim down the binary of a CLI project (disco) I'm developing. It links OPA alongside several cloud SDKs (AWS/Azure/GCP Go SDKs, currently) and linking opa/v1/ast adds ~600MB to the binary, much larger than OPA's own code size (something like 35mb, as you say).

I tracked it down to a Go linker dead-code-elimination (DCE) issue:

• ast.NewCompiler().Compile() unconditionally runs the checkTypes stage
• checkTypes stage reaches internal/gojsonschema (errors.go, schema.go)
• gojsonschemauses stdlib text/template for its error messages
• text/template's evalField/evalCall machinery calls reflect.Value.MethodByName() with a non-constant argument in order to support the {{.Method}} syntax.

Go linker's dead-code pass cmd/link/internal/ld/deadcode.go treats any reachable call to MethodByName with a non-constant arg as reachable. Therefore, the linker keeps every exported method on every type that ever crosses an interface boundary, which causes disco's AWS SDK clients (tons of method surfaces and boxed into http.RoundTripper/middleware interfaces) to balloon back to full size instead of getting pruned to just the operations they actually call.

To confirm this wasn't something else, I had Claude build disco using linker dump flags (go build -ldflags=-dumpdep) and some minimal probe builds. A probe that imports only ast and calls Compile() on an empty module set (never touching topdown or the render_template builtin at all) still reproduces the full 750+ mb binary. This makes me think the trigger is specifically checkTypes calling gojsonschema and not the Rego-level template builtin, where text/template is also used.

I then built another probe binary linking only our internal/policy OPA wrapper without any cloud SDK code. It was 28MB, stripped. disco's AWS SDK code alone (without internal/policy) floors at 175MB stripped. Summed, that's 203MB but the same two components linked into one binary come to 777MB

As a proof of concept, I forked OPA locally and had Claude rewrite the two gojsonschema files plus v1/topdown/template.go to do manual string formatting/token scanning instead of going through text/template, removing every reflect.MethodByName call from the reachable graph. That patch alone brought our combined binary down by 76%, with identical test output and byte-identical findings.

I have not validated this assertion but Claude thinks that "the fix seems narrow:"

gojsonschema's error-message formatting doesn't need arbitrary method dispatch, so swapping its text/template usage for plain fmt.Sprintf/string building (or a small non-reflective template stand-in) would remove the linker trigger for every downstream consumer of ast.Compiler, without touching the render_template builtin or any user-facing behavior.

As @kruskall already linked, this is also filed upstream as golang/go#72895 (the general MethodByName-defeats-DCE problem) and a Go proposal for a linker-level opt-out (golang/go#72888) was rejected as unsafe to offer generically. It seems like a source-level fix in internal/gojsonschema is the only realistic path to closing this for OPA consumers.

[srenatus]

If you'd be willing to jump in, I'd review a pull request with a change that does what needs to be done without reflect.MethodByName. It's sounds enticing, cutting down the binary size for importers certainly is a reasonable ask. A binary that won't fit onto a CD-R is a bit of a disaster, I'd say 😅