[typespec-go] Generated unmarshalling errors use %v instead of %w (non-wrapping fmt.Errorf)

[FumingZhang]

Summary

The TypeSpec Go emitter (@azure-tools/typespec-go) generates the JSON unmarshalling error in models_serde.go with the non-wrapping %v verb:

return fmt.Errorf("unmarshalling type %T: %v", a, err)

It should use the wrapping %w verb — as the legacy @autorest/go emitter did, and as the rest of azure-sdk-for-go does:

return fmt.Errorf("unmarshalling type %T: %w", a, err)

Why this matters

• %v flattens the error, so errors.Is / errors.As can no longer inspect the underlying unmarshalling error.
• It is a regression relative to the @autorest/go output, which wrapped with %w.
• It trips standard error-wrapping lint rules (errorlint, and go vet's "non-wrapping format verb for fmt.Errorf"), failing CI for repos whose generated SDKs are linted.

Repro / evidence

Any typespec-go–generated SDK on main shows it. Example from official azure-sdk-for-go:

sdk/resourcemanager/postgresql/armpostgresqlflexibleservers/models_serde.go

return fmt.Errorf("unmarshalling type %T: %v", a, err)

(file header: // Code generated by Microsoft (R) Go Code Generator. DO NOT EDIT.)

autorest.go–generated SDKs use %w in the identical spot.

Version

@azure-tools/typespec-go 0.14.2

Expected fix

In the emitter template that renders the unmarshalling helper, change the error verb from %v to %w.

[JiaqiZhang-Dev]

Hi @FumingZhang, is this an urgent issue? could you help share more context about it? The PR is ready now, but given that Go's architect is OOF, we should probably wait until he's back before releasing the new emitter.

[FumingZhang]

Not that urgent. After migrating our internal test-purpose SDK to the typespec emitter, I found the issue and a workaround: just replace %w with %v after generation.