Skip to content

[Bug] Authentication_key and Address Fields Incorrectly Parsed as Numbers in OpenAPI Spec UI #17160

@WGB5445

Description

@WGB5445

🐛 Bug

Description

In the OpenAPI documentation at https://fullnode.mainnet.aptoslabs.com/v1/spec#/operations/get_account, the authentication_key field (and other fields of type Address) is unexpectedly being parsed and displayed as a number rather than as a string.

Expected Result

{
  "sequence_number": "32425224034",
  "authentication_key": "0x88fbd33f54e1126269769780feb24480428179f552e2313fbe571b72e62a1ca1"
}
Image

Actual Result

{
  "sequence_number": "32425224034",
  "authentication_key": 6.195948399647823e+76
}
Image

Root Cause

The issue seems to stem from how the YAML spec is being parsed:

The YAML is rendered through here, which loads the spec in YAML format.

<body>
<elements-api
apiDescriptionUrl="spec.yaml"
router="hash"
layout="sidebar"
hideInternal="true"
/>

At here, values of the address type are defined as string, but due to how YAML is parsed in the Swagger UI, long hexadecimal values that resemble numbers can be misinterpreted.

aptos-core/api/doc/spec.yaml

Lines 11486 to 11496 in 84ff485

Address:
type: string
format: hex
description: |
A hex encoded 32 byte Aptos account address.
This is represented in a string as a 64 character hex string, sometimes
shortened by stripping leading 0s, and adding a 0x.
For example, address 0x0000000000000000000000000000000000000000000000000000000000000001 is represented as 0x1.
example: 0x88fbd33f54e1126269769780feb24480428179f552e2313fbe571b72e62a1ca1

Suggested Fix

Change the loading method in spec.html to use the JSON version of the spec instead of the YAML version. JSON enforces correct typing and prevents these misparsing issues.

....
    <elements-api
      apiDescriptionUrl="spec.json"
      router="hash"
      layout="sidebar"
      hideInternal="true"
    />
.....

Impact

Switching to the JSON version of the spec should not introduce any functional issues, as long as both the YAML and JSON specs are consistently generated from the same source.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions