fix(webvh): decode the daemon's camelCase DID-management response - #609
Merged
Conversation
The VTA's RequestUriResponse mirror (POST /api/dids reserve + /api/dids/register)
lacked #[serde(rename_all = "camelCase")], but the daemon
(did-hosting-common::RequestUriResponse) serializes camelCase — so `did_url`
arrives as `didUrl` and the body failed to decode ("webvh-server response parse
error"), breaking the publish path right after auth succeeded.
Add the camelCase rename to match the daemon (the same alignment #606 applied to
the auth response wire types). Regression test deserializes the daemon's real
`{mnemonic, didUrl}` body.
Signed-off-by: Glenn Gore <glenn@affinidi.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
1 participant
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.
Problem
After a VTA authenticates + is authorized to a
did-hosting-daemon(via #604, #606, and affinidi-webvh-service#55), the publish path fails at path reservation:webvh-server response parse error: error decoding response body for POST /api/dids.The daemon's
RequestUriResponse(did-hosting-common/src/types.rs) carries#[serde(rename_all = "camelCase")], so it serializesdid_urlasdidUrl. The VTA's mirrorRequestUriResponse(vta-service/src/webvh_client.rs) lacked the rename and expected snake_casedid_url→ serde fails to decode → the whole publish path (bothPOST /api/didsandPOST /api/dids/register, which reuse this type) breaks.Fix
Add
#[serde(rename_all = "camelCase")]to the VTA'sRequestUriResponse— the same wire-alignment #606 applied to the auth response types. One attribute; no behavior change beyond decoding the daemon's actual shape.Test
request_uri_response_deserializes_camelcase_daemon_bodydeserializes the daemon's real body{"mnemonic":"...","didUrl":"..."}and asserts both fields populate.cargo test/clippy/fmt -p vta-service --features webvh,didcommgreen.Context
Found in a live cross-service run (a VTA provisioning a
did:webvhagent with aWEBVH_SERVER). With this, path reservation decodes and the flow proceeds to log publication. (A separate daemon-side issue then surfaces: the publish path's IDNA host validation rejects the percent-encodedhost%3Aportform of adid:webvhidentifier for non-standard-port hosts — filed/handled separately.)