Error codes
Every failure the native core reports carries a stable code. Branch on the code, not on the message: a core failure’s message is fixed text for each kind of failure, such asIndex not found., with no URLs, file paths or index names. An argument the SDK rejects
itself keeps a message that describes it. (Python moss 1.15.0+, @moss-js/moss 1.16.0+,
@moss-dev/moss-web 1.4.0+, Elixir moss 1.5.0+, Swift SDK 0.8.0+)
Each SDK exposes the code in its own form:
Some errors an SDK raises before it calls the core carry no code. In Python a closed
MossClient raises RuntimeError and some argument checks raise ValueError or TypeError;
in JavaScript a closed client or session and createIndex with no documents throw a plain
Error; in the browser queryMultiIndex([]) throws a plain Error. The Python and
JavaScript web source methods raise ManageApiError. Elixir and Swift report their own
argument checks as a %Moss.Error{} and a MossError too.
detail holds the core error text: diagnostic text for logs and support, at most 512 bytes,
and not a stable contract. It names the operation or host instead of a request URL, and the
file instead of an absolute path. A failed response contributes only its HTTP status and the
error code its body names, such as HTTP 403 Forbidden: AccessDenied.
A bulk load reports the code of each index it could not load next to the message:
LoadIndexesResult.failed_codes in Python
and Elixir, and failedCodes in
JavaScript,
the browser and
Swift.
Error reference
Common scenarios
Search results are irrelevant
- Try hybrid search: lower
alphafor more keyword matching (default is0.8): - Check document chunking: very long documents dilute embedding signal. Keep chunks under about 1200 characters, cut at sentence boundaries - see Chunking tips.
- Switch models: try
moss-mediumlmfor higher accuracy.
SDK error behaviour
- Most methods throw if the target index does not exist.
createIndex()throws if the index already exists.loadIndex()throws if the index does not exist in cloud storage or loading fails. With acachePath(cache_pathin Python) and a snapshot already on disk, it serves that snapshot instead when the cloud is unreachable or answers with a temporary error, while a 401, 403 or 404 still throws. (Python moss 1.14.0+, @moss-js/moss 1.15.0+)
"failed", its JobStatusResponse.error will be non-null. The job’s currentPhase (see JobPhase) can hint at where it failed - a job stuck on downloading usually means a network issue.
Still stuck?
- Join the Moss Discord for community help
- Open an issue on GitHub