@mica/sdk (SDK contract v1)
    Preparing search index...

    Class ServiceRefusal

    The server said no, and said which no (MICA-310).

    A refusal the server meant for the player arrives as { error, key, params? } (server/lib/ServiceEndpoint.ts): key names an entry in the shell's server catalog and error is the English beside it. The phone's fetchNui turns that reply into this, with message already in the player's language — so anything that shows the message shows exactly what it did before — and the key kept, so code can tell one refusal from every other failure without comparing text a translator is free to reword.

    Only a reply that named a key becomes one. A timeout, a malformed request, a missing server half, an add-on handler's own addonError(...) text (keyless by design — it cannot speak in micaOS's catalog) and every throw on this side stay a plain Error, because there is no key to keep. The generic "something went wrong" is keyed (server.generic), so it is one; name the key you mean rather than asking whether there was any.

    A sandboxed add-on gets the same class: the shell sends the key across postMessage beside the message and the frame rebuilds it (host/iframe/remote.ts). Constructing one yourself convinces nothing but your own code — the shell never accepts one from a frame.

    Hierarchy

    • Error
      • ServiceRefusal
    Index
    • Parameters

      • key: string

        The catalog key the server named, server.jobs.lineUnavailable say. Never translated.

      • message: string

      Returns ServiceRefusal

    key: string

    The catalog key the server named, server.jobs.lineUnavailable say. Never translated.