Skip to content

Conversation

@mfori
Copy link
Member

@mfori mfori commented Nov 28, 2025

Document custom error messages in the input schema, introduced by apify/apify-shared-js#567 (based on the specification here)


Note

Documents custom validation error messages for input schema and links them from the spec and index.

  • Docs:
    • Add new guide input_schema/custom_error_messages.md explaining errorMessage usage, supported validation keywords, nesting, and best practices.
    • Update input_schema/specification.md to include errorMessage in input field properties table with link to the new page.
    • Update input_schema/index.md to reference the spec, secrets, and new custom error messages guide.

Written by Cursor Bugbot for commit 19d0412. Configure here.

@mfori mfori requested review from marcel-rbro and valekjo November 28, 2025 14:05
@mfori mfori self-assigned this Nov 28, 2025
@mfori mfori requested a review from TC-MO as a code owner November 28, 2025 14:05
@mfori mfori added the t-console Issues with this label are in the ownership of the console team. label Nov 28, 2025
@github-actions github-actions bot added this to the 128th sprint - Console team milestone Nov 28, 2025
@apify-service-account
Copy link

Preview for this PR was built for commit 19d0412 and is ready at https://pr-2121.preview.docs.apify.com!

@apify-service-account
Copy link

Preview for this PR was built for commit 417f583 and is ready at https://pr-2121.preview.docs.apify.com!

Copy link
Member

@valekjo valekjo left a comment

Choose a reason for hiding this comment

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

Looks good

Copy link
Contributor

@marcel-rbro marcel-rbro left a comment

Choose a reason for hiding this comment

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

Well written and structured. I like that the beginning of the page is very readable. I am not sure about the last section though.

Comment on lines 103 to 112
## Best practices

While custom error messages can improve the user experience by providing clearer guidance, it's generally better to rely on the default error messages unless there's a specific need for customization. Only use custom error messages when they significantly help users understand the requirements better than the default messages.

If you do decide to use custom error messages, follow these best practices:

1. **Be specific** - Clearly explain what is required or what went wrong
2. **Be concise** - Keep messages short and to the point
3. **Be helpful** - Provide guidance on how to fix the issue
4. **Be consistent** - Use a similar tone and style across all messages
Copy link
Contributor

Choose a reason for hiding this comment

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

I am not sure about this entire section. Do we want to be the source of information about how to write error messages? @TC-MO

Copy link
Contributor

Choose a reason for hiding this comment

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

Good question tbh. It feels like this is better suited for Academy then our Platform docs, let me think a bit on that. Apart from that:

  1. Bold is for UI elements. (at least for now), so it should be either italics, or no emphasis whatsoever.
  2. Ordered lists should be done with all 1. since Docusaurus can handle then the numbering while rendering the page and maintenance is much easier

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

Labels

t-console Issues with this label are in the ownership of the console team.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants