[zaidrain06]

What was changed

Excluded temporal.api.compute.v1.* messages (ComputeProvider, ComputeScaler, ComputeConfig, ComputeConfigScalingGroup, ComputeConfigScalingGroupUpdate) from payload visitation in cmd/proxygenerator/interceptor.go and regenerated proxy/interceptor.go.

Updated proxy/payload_walker_test.go and added TestVisitPayloads_SkipsComputeConfigPayloads in proxy/interceptor_test.go.

Why?

Fixes temporalio/temporal#12970

ComputeProvider.details and ComputeScaler.details are temporal.api.common.v1.Payload fields that store control-plane compute provider/scaler configuration read directly by the Temporal server (serialized with the default data converter), rather than end-user workflow payload data.

Because cmd/proxygenerator/interceptor.go previously generated visitPayloads traversal for all messages transitively containing common.v1.Payload, NewPayloadVisitorInterceptor (and SDK payload codecs) visited and encrypted ComputeProvider.details and ComputeScaler.details during CreateWorkerDeploymentVersion, UpdateWorkerDeploymentVersionComputeConfig, and ValidateWorkerDeploymentVersionComputeConfig, causing the server to fail when unmarshaling the encrypted compute configuration.

With this change:

• CreateWorkerDeploymentVersionRequest, UpdateWorkerDeploymentVersionComputeConfigRequest, ValidateWorkerDeploymentVersionComputeConfigRequest, and ComputeConfig* payloads are not visited/encrypted by payload codecs.
• WorkerDeploymentVersionInfo still visits Metadata.Entries while leaving ComputeConfig untouched.
• (cd ./cmd/proxygenerator && go run ./ -verifyOnly) and go test -v ./proxy pass.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}