Each contract crate defines its own error enum. Produce a single reference mapping every error to its numeric code, the condition that raises it, and the corrective action — the page a developer lands on after a failed transaction.
Proposed steps:
- Create
docs/reference/errors.md.
- Document every variant in
contracts/shade/src/errors.rs with its discriminant, the functions that can raise it, the exact triggering condition, and how to fix it.
- Do the same for
account, escrow, escrow_factory, ticketing, ticketing_factory, and subscription, in clearly separated sections, noting that codes are only unique within a contract.
- Explain how a Soroban error surfaces in CLI output and in SDK client errors, with an example of reading the code from a failed transaction.
- Add a troubleshooting table for the most frequently hit errors, mapping symptom → likely cause → fix.
- Document the convention for adding a new error variant (append only; never renumber) and link it to the upgradeability rules.
Acceptance criteria:
docs/reference/errors.md exists and covers every error enum in the workspace.- Each variant lists its code, trigger, and remedy.
- An example of extracting an error code from a failed transaction is included.
- The append-only numbering convention is documented.
Each contract crate defines its own error enum. Produce a single reference mapping every error to its numeric code, the condition that raises it, and the corrective action — the page a developer lands on after a failed transaction.
Proposed steps:
docs/reference/errors.md.contracts/shade/src/errors.rswith its discriminant, the functions that can raise it, the exact triggering condition, and how to fix it.account,escrow,escrow_factory,ticketing,ticketing_factory, andsubscription, in clearly separated sections, noting that codes are only unique within a contract.Acceptance criteria:
docs/reference/errors.mdexists and covers every error enum in the workspace.