feat(cli): fix issue with content hash handling#9
Conversation
CI Summary
Release - PassedTest this PR Download artifact (GitHub CLI required): gh run download 21921655089 -n cli-preview-0.0.0-pr.9 -R paritytech/dotns-sdkInstall globally:
Verify: dotns --helpLabelspkg: cli |
waytwotall
left a comment
There was a problem hiding this comment.
Nit : please comment on why you are changing code or what the code is doing
Right, please see the description, do i need to add more info @waytwotall |
Hi Spha - the description and release notes are great - It is more of a nit - I think that often people are reading through code and looking at entry and exit points for functions and code flows - sometimes it can be obvious but often the code is the artefact and the issues and release notes are lost |
Description
Fix contenthash decoding in
contentManagement.ts. ThedecodeContenthashToCidfunction passed0x-prefixed hex directly to@ensdomains/content-hashwhich expects raw hex without the prefix. This causedgetCodecto misparse the bytes, producing Invalid CID version 112 errors when reading existing on-chain contenthashes. The fix consolidates on the sharedcid.tsutilities which already handle0xstripping correctly.Type
Package
@dotns/cliRelated Issues
Fixes
Checklist
Code
bun run lintpassesbun run formatpassesbun run typecheckpassesDocumentation
Breaking Changes
Testing
How to test:
dotns content set <name> <cid>, the current field should now decode correctly on first run instead of showing Unable to decodedotns content view <name>, should display the CID instead of erroring with Invalid CID version 112Notes
Same root cause as the gateway
slice(2)bug. The@ensdomains/content-hashlibrary expects raw hex (e301017012...) but was receiving0x-prefixed hex (0xe301017012...), causing byte offsets to shift. Thecid.tsutility already handled this correctly,contentManagement.tshad a duplicate implementation that didn't.