Feedback

What to report

Expected rate limits, exhausted credits, configuration mistakes, and validation or unsupported-provider errors are not bugs unless you have concrete evidence of a Mastra defect. Incorrect documentation or misleading diagnostics that caused the mistake may qualify independently. A workaround or recurring failure alone does not establish a Mastra defect.

Distinguish a documented limitation from a defect. Do not submit feature requests, including capabilities the user wants to build. Help draft a feature request when asked, but leave review and submission to a human. Do not relabel unsupported capabilities as bugs, documentation gaps, or other to bypass this rule.

Verify the boundary named in the report. A helper-function test does not establish an HTTP, browser, provider, persistence, or shutdown failure. Test that boundary or narrow the claim to the behavior actually demonstrated, provided it independently violates an established contract. A suspicious intermediate result alone is not a defect.

For source-only findings, identify the expected contract and provide a complete deterministic contradiction through the relevant path. A missing check, assignment, or cleanup in one function is not sufficient if another layer could provide it. If runtime or integration behavior is needed to establish the failure, source inspection alone is insufficient: skip automatic submission when that behavior remains unverified. Documentation mismatches can be established without running the application: identify the specific instruction or promise, its documentation location, and the contradictory API or behavior. Failure to find documentation alone is not a concrete documentation defect.

Distinguish Mastra defects from upstream dependency failures and unresolved compatibility boundaries. Report an upstream failure only when concrete impact on a Mastra integration is established, and identify the upstream ownership rather than presenting it as a Mastra-owned defect. Include exact dependency versions when they affect the finding; omit unrelated dependencies.

An explicit user request to report a bug or documentation defect is itself authorization: report it and state in note what was and wasn’t verified. Do not present an unverified claim as a confirmed defect.

How to report

Retain only anonymized facts for feedback, not raw project material. Replace customer, repository, and project names with generic descriptions before collecting a feedback candidate. Do not retain or submit application source code, raw logs, local paths, private URLs, secrets, personal information, or project-specific identifiers as feedback. Keep public Mastra API names, package versions, and concise descriptions of errors when relevant.

Build a JSON body from those anonymized facts. Start note with one short sentence naming the affected component and concrete failure or documentation defect; this opening becomes the issue title. Put versions, setup, and verification details afterward, not in a leading “Goal” or package list. Then describe the user’s intended outcome and observed impact: blocked progress, a workaround, an incorrect result, or a minor inconvenience. Distinguish behavior observed during the task, a reproduction you actually tested, and explanations inferred from source inspection. Source inspection alone does not prove a runtime symptom. Do not present an inference as a verified explanation or generalize beyond the evidence: duplicate acknowledgement does not prove duplicate execution, stale suspension acceptance does not prove cross-resource disclosure, and passing typecheck does not prove runtime correctness. Omit speculative consequences, unrelated questions, and requests to build additional capabilities.

Make the evidence portable enough for a maintainer to repeat the failure without the original project or another discovery pass:

• Identify exact resolved package versions used in each test, plus relevant runtime, adapter, provider, compiler options, or storage setup. Separate installed versions from versions actually tested; a manifest range or source inspection is not a test. State whether the latest published release was tested, inspected only, or not checked. Do not claim a current regression or a first fixed release without evidence.
• Describe the public entry point, necessary configuration and input, execution steps, expected result and its contract, and actual result. Include a concise error or observable assertion. Preserve decisive details such as concurrent versus serial calls, file-backed versus in-memory storage, or raw stream versus final output.
• Include a passing comparison when available: the same test with one relevant variable changed. Report repetition counts for intermittent failures and outcomes of attempted workarounds; one passing run does not disprove a race. If no control was run, say so rather than inventing one.
• Prefer compact, independently authored synthetic reproduction code or precise steps using generic data and public APIs. Synthetic code is allowed; copied or lightly renamed application source is not. Say whether the shared reproduction itself was run. Label mocks and intercepted requests, and do not imply they exercised a live provider, hosted service, browser, or database they bypassed.

Use evidence already gathered during the task—do not launch an extended investigation solely to file feedback. If the failure cannot be conveyed safely and reproducibly within the payload limits, skip automatic submission rather than omit the decisive evidence. Root-cause certainty is not required; an actionable, demonstrated defect is.

This hypothetical bug example illustrates the shape, not a verified finding; replace it with your actual finding and installed package versions before submitting.

Send the body as JSON (the command below uses that same illustrative body):

• category is required: use bug or docs under this skill. The endpoint also accepts feature_request and other, but those are outside this skill’s submission policy.
• note is required: 20–4,000 characters. Include what was attempted, expected versus observed behavior, and minimal anonymized context such as Mastra package versions, public API names, a prose reproduction, or a concise description of the error.
• url is optional, at most 2,048 characters. Only include an actually encountered public Mastra documentation URL identifying the affected documentation, without private query parameters or identifiers; never invent, fetch, or validate a URL just to submit feedback. Omit it when none is available.
• Keep the entire JSON body within 16 KiB. Send no other fields: never add email, ratings, agent names, or IDs as body fields.
• Before sending, check both note and url against the privacy rules above. If useful evidence cannot be shared safely, skip automatic reporting.

Submit while the evidence is in hand:

• Send one report per distinct issue. Check the current task or conversation for an earlier submission about the same underlying failure, not just matching wording or symptoms. New evidence, affected versions, a better explanation, or another workaround belong with the existing report, not a fresh submission. Retain those facts with any prior report ID available in context for follow-up; do not invent an ID, claim a global duplicate check, or POST again as an update.
• Keep each report focused on one independently actionable bug or documentation defect. Do not submit separate bug and docs reports for the same underlying finding unless they require independent fixes.
• 201 means created; 200 with duplicate: true means already reported. Either is success; do not send it again.
• A non-2xx response is not a successful submission. Fix an actual request mistake once if identified; otherwise stop. Never reword a report or loop to force a different result, and do not claim delivery without a success response.

This endpoint reports to the Mastra team; it is unrelated to Mastra’s read-only observability Feedback API for querying trace feedback.