Skip to main content

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 as Index 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 alpha for more keyword matching (default is 0.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-mediumlm for 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 a cachePath (cache_path in 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+)
If a job reaches "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?