The Move representation of an account address sometimes lacks padding / leading zeroes but other APIs have padding zeroes, how can I reconcile this?

[banool]

During testing, we found out a problem: events can include abridged addresses, they lack the leading / padding zeros. The problem is that the GraphQL API doesn't recognize such addresses. As an example, see TransferEvent in this transaction. The object in TransferEvent there is 0x22b8fb2552abd8d5627d683d9bbb846e1c816e654cc039996d30c9d1eb285f2, but the long format should be 0x022b8fb2552abd8d5627d683d9bbb846e1c816e654cc039996d30c9d1eb285f2.

So this request for token data doesn't return any results:

query MyQuery {
  current_token_datas_v2_by_pk(
    token_data_id: "0x22b8fb2552abd8d5627d683d9bbb846e1c816e654cc039996d30c9d1eb285f2"
  ) {
    token_data_id
  }
}

However if I set token_data_id to 0x022b8fb2552abd8d5627d683d9bbb846e1c816e654cc039996d30c9d1eb285f2 it works.

[banool]

Unfortunately this is a deficiency on our side. For legacy reasons, some representations of account addresses are not AIP-40 compliant and therefore return addresses without padding zeroes (abridged as you say). One big culprit is the JSON representation of a Move resource, leading zeroes are dropped.

All you can do is normalize the address client side. For example, in Typescript with the TS SDK, with a function like this:

import { AccountAddress } from '@aptos-labs/ts-sdk';

export function normalizeAddress(address: string) {
  return AccountAddress.from(address).toStringLong();
}

Or just something like this:

export function normalizeAddress(address: string): string {
  // Check if the input address starts with "0x"
  if (address.startsWith("0x")) {
    // Remove the leading "0x" before normalizing
    address = address.substring(2);
  }
  // Return the normalized address with a "0x" prefix, and ensure it is 64 characters long
  return "0x" + address.padStart(64, "0");
}