[Bug] Aptos TS/JS SDK calls the getAccountResources method to return a problem, the first 0 of the address is omitted.

[cryptosunshine]

🐛 Bug

To reproduce Typescript

Code snippet to reproduce

# const client = new AptosClient('https://fullnode.devnet.aptoslabs.com');
# const address = "0x0ed74576610ef9dcc5a89b9aee9203fa31ca28189f34591406dbce556a6e5aae"
# client.getAccountResources(address).then(result)

Stack trace/error message

...
4: {type: '0xed74576610ef9dcc5a89b9aee9203fa31ca28189f34591406dbce556a6e5aae::Message::MessageHolder', data: {…}

Expect to return

...
4: {type: '0x0ed74576610ef9dcc5a89b9aee9203fa31ca28189f34591406dbce556a6e5aae::Message::MessageHolder', data: {…}

Question

In the address in the type,0 is missing during base conversion.

Supplementary question.

[jjleng]

Thanks for reporting. @banool, API returns the address with the leading 0 missing.

[banool]

I'll take a look, though this might be expected behaviour. Confusingly one of these trims zeroes while the other doesn't. I can audit this in the new API and make it work the same. Stay posted.

[banool]

Note, this behavior comes straight from the Move layer.

[gregnazario]

This comes straight from the Move layer.

Struct names, function names, and other identifiers use a short str approach which trims the leading 0s

[github-actions[bot]]

This issue is stale because it has been open 45 days with no activity. Remove the stale label or comment - otherwise this will be closed in 15 days.

[github-actions[bot]]

This issue is stale because it has been open 45 days with no activity. Remove the stale label or comment - otherwise this will be closed in 15 days.

[davidiw]

I think whatever we have is going to be in a quirky state for a long time... but we should probably have a longer term tracking issue to identify where 0 is truncated....