feat: sync with ans Discovery Profiles - #101
Merged
Merged
Conversation
Signed-off-by: James Hateley <jhateley@godaddy.com>
Signed-off-by: James Hateley <jhateley@godaddy.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Related issue
Fixes #87
Summary
Issue #87 asked us to bring the Java SDK to parity with the ANS reference implementation. That implementation shipped Adapter-style DNS Discovery Profiles (agentnameservice/ans#25): the ANS-family DNS discovery styles (SVCB and TXT) and the trust records that go with them.
Most of that sync landed already in commit 9c26e91 (PR #92). That commit regenerated the models from the ANS repo spec. It also added the v1/v2 API routing and the first cut of
discoveryProfileshandling. This PR is the final fix on top of that work. It corrects thediscoveryProfilesdefault and the version semantics.discoveryProfilesis a v2-only field. The v1 lane ignores it on the server.The first cut defaulted the field to
[ANS_DNSAID]. It removed the field from the wire body without notice when the target was v1. That approach hid a client mistake. It also sent a default that the caller did not choose.Now the behavior is different:
@JsonInclude(NON_EMPTY).discoveryProfilesselection on the v1 lane is a client misconfiguration. The client rejects it withIllegalArgumentExceptioninstead of a silent drop. The message tells the caller to remove the selection or to build the client withApiVersion.V2.Changes
AgentRegistrationRequest: the defaultdiscoveryProfilesis now an emptyLinkedHashSet. The getter has the@JsonInclude(NON_EMPTY)annotation, so the client omits the empty default.RegistrationService: addedrejectDiscoveryProfilesOnV1. It throws when a caller uses a non-empty selection on v1. Serialization no longer removes the field.AnsApiClient: removed the unusedserializeToJsonWithoutFieldJSON-tree helper.Testing
AnsApiClientTest, which covered the deleted helper.ApiVersionRoutingTest: v1 omits the empty default. v1 rejects an explicit selection before any HTTP call.RegistrationClientTest: v2 sends an explicit selection on the wire. v2 omits the empty default.e2e tests ran against v1 and v2.
AI assistance
Assisted-by: Claude Code (claude-fable-5)
Checklist
git commit -s) certifying the DCO