Backport of Refactor Txn API to use AgentService and add TaggedAddresses support into release/1.20.x #22250
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport
This PR is auto-generated from #22248 to be assessed for backporting due to the inclusion of the label backport/1.20.
🚨
The person who merged in the original PR is:
@nitin-sachdev-29
This person should manually cherry-pick the original PR into a new backport PR,
and close this one when the manual backport PR is merged in.
The below text is copied from the body of the original PR.
Description
This PR fixes the Golang Consul API Client Library Unmarshalling error when using the Transaction API with Service that has
TaggedAddresses, see #22180 (comment).Below is a summary of the current Service Transaction Workflow when using the Golang Consul API Client Library:
The
Txnclient specifies Service information to update as an api.AgentService in an api.ServiceTxnOp to submit to the AgentTxnendpoint.In the Agent
Txnendpoint, it converts the api.AgentService to a structs.NodeServicethat is used internally for applying the transaction.
After the transaction is applied, the structs.TxnResponse that is returned to the client contains the Service information as a structs.NodeService in the structs.TxnServiceResult.
The
Txnclient tries to decode the returned response as an api.TxnResponse which uses api.CatalogService for the Service TxnResult.When a Service has
TaggedAddresses, the decoding fails withjson: cannot unmarshal object into Go struct field CatalogService.Results.Service.TaggedAddresses of type string. This is because structs.NodeService has TaggedAddresses as amap[string]structs.ServiceAddress, while api.CatalogService has TaggedAddresses as amap[string]stringwhich is intended to be the node'sTaggedAddressesand the Service's TaggedAddresses` is in ServiceTaggedAddresses field.The proposed fix here is to change the Golang Consul Client Library to use api.AgentService for the Service TxnResult which has fields that are compatible for conversion from structs.NodeService
returned from the agent endpoint.
This change will require applications that use the Golang Consul Client Library for Service Transactions to do a small code change once they choose to upgrade the library to the new release (they will get notified with compile errors). Considering that any such clients are already in a broken state (if there are any such users besides us), it should be fine ok require such a change. api.AgentService appears to be the more appropriate Service
TxnResulttype, it matches the Txn input type and it is the return type for other endpoints such ashealth/service.If we do still want to maintain api.CatalogService as the Service
TxnResulttype, then we could just add a best-effort conversion from api.AgentService to api.CatalogService before returning in the client library.PR Checklist
Overview of commits