Hi @cryptoschindler ,
Thanks for the error list. That certainly makes sense to describe the issue I was previously having where I wasn’t signing the get_full_neuron request. I’ve since moved on from that and I’m facing the issue of trying to get the results of the signed get_full_neuron request.
I apologize, I’m thoroughly confused by your response. Your document explains that when we sign a message and send it we will receive a Request ID, and then the document says:
Unfortunately the Request ID can’t be inspected as the Identity on the hot machine is not the one that has signed the corresponding message we just sent.
Okay. So how can we get more information from the Request ID? dfx canister --help describes the use of request-status but that term does not exist in the guide you created.
When I try to run the command I get the following:
$ dfx canister --no-wallet --network=$NETWORK request-status $REQUESTID $CANISTER
An error happened during communication with the replica: error sending request for url (https://ic0.app/api/v2/canister/rrkah-fqaaa-aaaaa-aaaaq-cai/read_state): http2 error: protocol error: not a result of an error
Another reports that he doesn’t get responses at all: All dfx request-status calls fail
And in the thread I previously forwarded people have been having issues with getting the status with a Request ID for a long time: How to read the result of sign/send just as we do with call
SO THE STATUS IS I DON’T KNOW HOW TO THE GET THE RESULTS OF A SEND COMMAND WITH A REQUEST ID. And I don’t see any evidence that anyone else does either.
In that discussion thread a new workaround was suggested that we can actually get results by passing the --status flag right after sending the send command. So I tried that and got an encoded result back. BUT the issue as I’ve previously described is that the results come back as a Certificate type and there are no instructions on how to actually decode that data that is coming back in this format.
I sincerely apologize if I’m missing something obvious, but I don’t understand how the guide addresses these roadblocks, and I’ve been keyword searching to try to understand. Again, I’m curious how exactly get_full_neuron was tested from an airgapped / sign/send setup? Was it tested in a test environment perhaps? Is there a current bug on the live IC? I’m very confused.
Thanks so much for your help.