Thread panic when calling `dkms debug kel` on a non-transferable identifier
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 0
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Description
I forgot that KELs may or may not be provided for non-transferable identifiers like witnesses and attempted the following command on the current dkms-demo b84670f that was running at the time and queried the first witness as so
daidoji@vLEIDALaptop1:~/ssi/dkms-bin$ ./target/debug/dkms debug kel --source http://172.17.0.1:3234/ --identifier "BDg1zxxf8u4Hx5IPraZzmStfSCZFZbDzMHjqVcFW5OfP" --sn 0
Registering out of order escrow with timeout: 60s
thread 'main' panicked at src/subcommands/debug.rs:75:72:
called `Result::unwrap()` on an `Err` value: Error("expected value", line: 1, column: 1)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
I can provide the back trace if that helps but I would expect the tool not to panic and just return that no KEL exists or something of the sort when using it erroneously in this manner.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at src/subcommands/debug.rs:75, where the debug kel command unwraps the failed result. Reproduce the command against the dkms-demo source using the non-transferable witness identifier and inspect the error path. Done means the command no longer panics and reports that no KEL exists or otherwise returns a user-facing error.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- cli
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 65/100