Skip to content

Conversation

@laviniat1996
Copy link
Collaborator

closes #1042

This doc adds all error codes I could find in the codebase for API v3.

@github-actions

This comment has been minimized.

Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the update to ecosystem/api/toncenter/v3-errors.mdx: there is one inline suggestion to align error message formatting with the style guide. Please apply the inline suggestion.

@github-actions

This comment has been minimized.

@verytactical
Copy link
Collaborator

Please ping when it's ready for final editing.

@verytactical verytactical added the 3p Reviewed by someone else (a third party). Used for filtering PRs. Don't mind this. label Nov 28, 2025
@novusnota
Copy link
Collaborator

/review

Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the updates in ecosystem/api/toncenter/v3-errors.mdx: I’ve left a couple of suggestions. Please apply the inline suggestions.

Comment on lines +7 to +8
| Status | Meaning |
| ------ | ------------------------------ |

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[HIGH] Numeric status columns not right-aligned

In the Overview table, the Status column header and separator (| Status | / | ------ |) do not specify right alignment, so the numeric HTTP status codes in that column render left-aligned. This violates the documented style rule that numeric columns must be right-aligned for readability and consistency (see contribute/style-guide-extended.mdx). The same pattern is repeated for all other Status columns on this page, so the misalignment affects every status code table in v3-errors.mdx. The primary location above points to the first occurrence; other instances share the same structural issue.

Suggested change
| Status | Meaning |
| ------ | ------------------------------ |
| Status | Meaning |
| ------:| ------------------------------ |

Please leave a reaction 👍/👎 to this suggestion to improve future reviews for everyone!

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the style guide doesn't fit this one. Left aligned error codes look better IMO
image
image

Comment on lines 7 to 13
| Status | Meaning |
| ------ | ------------------------------ |
| 401 | Missing required field |
| 404 | Data not found |
| 409 | Resource exists but wrong type |
| 422 | Invalid request parameters |
| 500 | Server-side failure |

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[HIGH] HTTP status literals lack code formatting

In the overview error table, the HTTP status values in the Status column are rendered as plain text (401, 404, 409, 422, 500) instead of using code formatting. The extended style guide requires code, filenames, paths, API endpoints, flags, and literals to use code formatting, which explicitly covers these protocol status codes (see https://github.com/ton-org/docs/blob/main/contribute/style-guide-extended.mdx?plain=1#L321-L324). Keeping these values unformatted makes them visually blend into surrounding prose and reduces the clarity of the reference. The same pattern appears in subsequent Status columns throughout the file and should be updated consistently.

Suggested change
| Status | Meaning |
| ------ | ------------------------------ |
| 401 | Missing required field |
| 404 | Data not found |
| 409 | Resource exists but wrong type |
| 422 | Invalid request parameters |
| 500 | Server-side failure |
| Status | Meaning |
| ------ | ------------------------------ |
| `401` | Missing required field |
| `404` | Data not found |
| `409` | Resource exists but wrong type |
| `422` | Invalid request parameters |
| `500` | Server-side failure |

Please leave a reaction 👍/👎 to this suggestion to improve future reviews for everyone!

@novusnota novusnota marked this pull request as draft November 28, 2025 18:18
@ton-org ton-org deleted a comment from ldt1996 Dec 1, 2025
Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the update to ecosystem/api/toncenter/v3-errors.mdx: I have one inline suggestion there, so please apply the inline suggestion.


| Status | Error | Fix |
| ------ | -------------------------------- | ----------------------------------------------- |
| `401` | `address of account is required` | Include the `address` parameter |
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[HIGH] Error strings use code font instead of quotation marks

The error message in the "Account & wallet info" table is rendered as a code span (address of account is required) instead of being enclosed in double quotation marks. This violates the style rule that log messages and error strings must appear verbatim in quotation marks for accurate copying and grepping (see https://github.com/ton-org/docs/blob/main/contribute/style-guide-extended.mdx?plain=1#L276-L295). The same pattern is repeated across the other error tables in this page (for example, boc is required, blocks not found, and similar entries), so readers cannot easily distinguish literal messages from surrounding prose. Consistently quoting error strings also keeps the documentation aligned with actual runtime messages and reduces the risk of subtle mismatches.

Please leave a reaction 👍/👎 to this suggestion to improve future reviews for everyone!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

3p Reviewed by someone else (a third party). Used for filtering PRs. Don't mind this.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[TON Center > API/v3 > Responses and errors]

4 participants