Jormungandr: /api/v0/account/{account_id} rest endpoint returns 400

Created on 3 Nov 2019  路  6Comments  路  Source: input-output-hk/jormungandr

Describe the bug
/api/v0/account/{account_id} does not work; the jcli equivalent command works as expected;

Mandatory Information

jcli 0.7.0-rc4 (HEAD-56906548, release, windows [x86_64]) - [rustc 1.38.0 (625451e37 2019-09-23)]
jormungandr 0.7.0-rc4 (HEAD-56906548, release, windows [x86_64]) - [rustc 1.38.0 (625451e37 2019-09-23)]

To Reproduce
Steps to reproduce the behavior:

  1. Make sure ca1s4qn8vt8k96w7uujz296kvfgas956lx2kjv8mdsspp83z6m7jgg8jnnypv9 has funds
  2. Execute - curl -X GET http://127.0.0.1:9000/api/v0/account/ca1s4qn8vt8k96w7uujz296kvfgas956lx2kjv8mdsspp83z6m7jgg8jnnypv9 --> 404 returned
  3. Execute - jcli rest v0 account get ca1s4qn8vt8k96w7uujz296kvfgas956lx2kjv8mdsspp83z6m7jgg8jnnypv9 --host "http://127.0.0.1:9000/api" --> expected output returned

Expected behavior
curl command should return the same output as the jcli command

Additional context

GET http://localhost:9000/api/v0/account/ca1s4qn8vt8k96w7uujz296kvfgas956lx2kjv8mdsspp83z6m7jgg8jnnypv9
400 | 511ms
GET /api/v0/account/ca1s4qn8vt8k96w7uujz296kvfgas956lx2kjv8mdsspp83z6m7jgg8jnnypv9 HTTP/1.1
Content-Type: application/json
Accept: application/json
User-Agent: PostmanRuntime/7.19.0
Cache-Control: no-cache
Postman-Token: 42338d95-1007-489b-bd2b-615793b61676
Host: localhost:9000
Accept-Encoding: gzip, deflate
Connection: keep-alive
HTTP/1.1 400 Bad Request
content-length: 0
date: Sun, 03 Nov 2019 09:48:50 GMT
curl -X GET http://127.0.0.1:9000/api/v0/account/ca1s4qn8vt8k96w7uujz296kvfgas956lx2kjv8mdsspp83z6m7jgg8jnnypv9
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0



md5-8daf5a67d02bc60dba73d1661de0e116



jcli rest v0 account get ca1s4qn8vt8k96w7uujz296kvfgas956lx2kjv8mdsspp83z6m7jgg8jnnypv9 --host "http://127.0.0.1:9000/api"
---
counter: 0
delegation:
  pools: []
value: 1000
invalid

Most helpful comment

Just to clarify a bit one way do get the hex from account.

If you already know the public key, goto step 2.

  1. Get the Public Key
jcli address info ca1s4qn8vt8k96w7uujz296kvfgas956lx2kjv8mdsspp83z6m7jgg8jnnypv9
---
discrimination: testing
account: ed25519_pk1gyemzea3wnhh8ysj3w4nz28vpdxhej45np7mvyqgfugkkl5jzpusfp725q
  1. Get the bytes (hex) out of the public key
echo ed25519_pk1gyemzea3wnhh8ysj3w4nz28vpdxhej45np7mvyqgfugkkl5jzpusfp725q | jcli key to-bytes
---
4133b167b174ef7392128bab3128ec0b4d7ccab4987db610084f116b7e921079

Do not worry about get the bytes out of a private key in the help message, since it works fine even for public key:

jcli key to-bytes --help
---
jcli-key-to-bytes 0.7.0
[email protected]
get the bytes out of a private key

USAGE:
    jcli key to-bytes [ARGS]

FLAGS:
    -h, --help       Prints help information
    -V, --version    Prints version information

ARGS:
    <OUTPUT_FILE>    output the key to the given file or to stdout if not provided
    <INPUT_FILE>     path to the private key to serialize in bytes Or read from the standard input

All 6 comments

Can you please try to replace ca1s4qn8vt8k96w7uujz296kvfgas956lx2kjv8mdsspp83z6m7jgg8jnnypv9 with 4133b167b174ef7392128bab3128ec0b4d7ccab4987db610084f116b7e921079 just to test? I suspect rest expects hex converted data and IIRC jcli does this before sending the request.

Note: Will check also myself a bit later since right now upgrading configs to master changes :hammer_and_wrench: :boom:

As @rinor said, also confirmed here

Also there is a WIP branch from @CodeSandwich related to this https://github.com/input-output-hk/jormungandr/commits/account_id_trim but not sure if it will be merged or not.

@rinor - you are right, as usual :). the hex value is working.

I suggest to still keep this open in order to have the user experience improved in some way (at some point) - either by updating the docs (and swagger), or by changing the functionality (low probability :) )

As of now the docs are correct:

  • OpenAPI say that hex is expected
  • JCLI docs say that bech32 is expected

At some point it must've been fixed, so I'll close the issue.

Just to clarify a bit one way do get the hex from account.

If you already know the public key, goto step 2.

  1. Get the Public Key
jcli address info ca1s4qn8vt8k96w7uujz296kvfgas956lx2kjv8mdsspp83z6m7jgg8jnnypv9
---
discrimination: testing
account: ed25519_pk1gyemzea3wnhh8ysj3w4nz28vpdxhej45np7mvyqgfugkkl5jzpusfp725q
  1. Get the bytes (hex) out of the public key
echo ed25519_pk1gyemzea3wnhh8ysj3w4nz28vpdxhej45np7mvyqgfugkkl5jzpusfp725q | jcli key to-bytes
---
4133b167b174ef7392128bab3128ec0b4d7ccab4987db610084f116b7e921079

Do not worry about get the bytes out of a private key in the help message, since it works fine even for public key:

jcli key to-bytes --help
---
jcli-key-to-bytes 0.7.0
[email protected]
get the bytes out of a private key

USAGE:
    jcli key to-bytes [ARGS]

FLAGS:
    -h, --help       Prints help information
    -V, --version    Prints version information

ARGS:
    <OUTPUT_FILE>    output the key to the given file or to stdout if not provided
    <INPUT_FILE>     path to the private key to serialize in bytes Or read from the standard input

Was this page helpful?
0 / 5 - 0 ratings