Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
iii-hq avatar

Iii Error Handling

  • 1.4k installs
  • 18.6k repo stars
  • Updated August 5, 2026
  • iii-hq/iii

iii-error-handling is an iii agent skill that implements resilient error handling across Node, Python, Rust, and browser workers using typed failure codes, retries, user-safe messages, and observability hooks.

About

iii-error-handling is an iii-hq skill documenting error classes for iii engine remote invocations and SDK-local failures across Node, Python, Rust, and browser workers. Agents must branch on exact code strings—such as function_not_found for missing registered handlers—rather than matching message text alone. The readme separates engine wire codes from SDK-local codes and maps typical handling for RBAC denial, timeouts, retryability, and handler failures. Developers reach for iii-error-handling when building production agent services that call iii functions over HTTP or embedded SDKs and need consistent user-safe errors plus observability hooks. Use it while interpreting thrown exceptions, designing retry policies, and surfacing actionable failures in multi-language iii deployments.

  • Typed error flows
  • Retry strategies
  • Safe user messaging
  • Integration resilience
  • Observability hooks

Iii Error Handling by the numbers

  • 1,399 all-time installs (skills.sh)
  • +48 installs in the week ending Aug 5, 2026 (Skillselion tracking)
  • Ranked #336 of 4,347 Backend & APIs skills by installs in the Skillselion catalog
  • Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/iii-hq/iii --skill iii-error-handling

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs1.4k
repo stars18.6k
Last updatedAugust 5, 2026
Repositoryiii-hq/iii

How do you handle iii engine SDK error codes?

Implement resilient error handling in iii agents and HTTP integrations—typed failures, retries, user-safe messages, and observability hooks for production agent services.

Who is it for?

Developers building production iii agents or HTTP integrations in Node, Python, Rust, or browser workers who need code-driven error branching.

Skip if: Generic REST APIs without iii engine/SDK surfaces, or apps that only match error message strings instead of documented codes.

When should I use this skill?

A developer hits iii function_not_found, RBAC denial, timeout, handler failure, or SDK-specific exceptions needing structured handling.

What you get

Typed error handlers, retry policies, RBAC denial paths, user-safe failure messages, and observability hooks for iii agents.

  • typed error handlers
  • retry policy rules
  • observability hooks

By the numbers

  • Covers iii error handling across 4 runtimes: Node, Python, Rust, and browser workers
  • Documents distinct engine wire codes separate from SDK-local error codes

Files

SKILL.mdMarkdownGitHub ↗

Error Handling

iii has two broad error classes: SDK/local errors and engine/remote invocation errors. Agents should branch on the error code instead of matching only message strings.

Error Codes

Branch on exact code strings, but keep engine wire codes separate from SDK-local codes.

CodeEmitted byMeaningTypical handling
function_not_foundEngine and SDK local dispatchNo registered function is available under that IDCheck function ID, worker install/startup, discovery, and trigger type hints
invocation_errorEngine invocation/router pathEngine failed to route, remember, or complete the invocationInspect engine logs, protocol state, and worker connectivity
invocation_stoppedEngine invocation handlerInvocation was cancelled or stopped by the engine/runtimeTreat as failed work; decide whether caller should retry
FORBIDDENRBAC / worker-gated engine functionsRBAC denied the actionDo not retry blindly; inspect policy, auth context, and allowed functions
timeoutEngine/worker wire error when a worker reports lowercase timeoutInvocation exceeded a timeout reported through the wire protocolTreat as timeout, but do not assume every SDK maps it to a timeout subclass
function_not_invokableSDK local dispatchRegistration exists but cannot be invoked as a normal local functionInspect registration/invocation type
invocation_failedSDK worker handler wrappersLocal worker handler, HTTP-invoked function wrapper, or SDK-side handler path failedInspect handler logs, stacktrace, and payload validation
TIMEOUTNode/Python SDK caller timeoutClient waited longer than trigger() timeoutIncrease timeout only if the workload is expected to run long; otherwise optimize or enqueue

Handler vs Engine Errors

  • Handler errors originate in user function code, SDK local dispatch, or HTTP-invoked endpoints.
  • Engine errors originate in routing, invocation state, RBAC, protocol handling, or worker-reported wire errors.
  • Queue retries only apply to enqueued work. Synchronous failures are returned directly to the caller.
  • Void dispatch does not return handler results, so use logs/observability for failures.

Retryability

  • Retry transient timeout, TIMEOUT, transport, or worker reconnect failures only when the operation is idempotent.
  • Do not retry FORBIDDEN without changing auth/policy.
  • Do not retry function_not_found by calling the same ID repeatedly; discover functions or install/start the missing worker.
  • For reliable background work, use TriggerAction.Enqueue({ queue }) and queue retry/DLQ policy.

SDK Surfaces

Node

import { InvocationError } from 'iii-sdk'

try {
  await iii.trigger({ function_id: 'orders::charge', payload })
} catch (error) {
  if (error instanceof InvocationError && error.code === 'FORBIDDEN') {
    throw new Error('Policy denied orders::charge')
  }
  throw error
}

Python

from iii import InvocationError

try:
    result = iii.trigger({"function_id": "orders::charge", "payload": payload})
except InvocationError as exc:
    if exc.code == "FORBIDDEN":
        raise RuntimeError("Policy denied orders::charge")
    if exc.code in ("TIMEOUT", "timeout"):
        raise RuntimeError("orders::charge timed out")
    raise RuntimeError(f"{exc.code}: {exc.message}")

Rust

match iii.trigger(request).await {
    Ok(value) => value,
    Err(iii_sdk::Error::Timeout) => {
        return Err("orders::charge timed out".into());
    }
    Err(iii_sdk::Error::Remote { code, message, .. }) if code == "FORBIDDEN" => {
        return Err(format!("policy denied: {message}").into());
    }
    Err(err) => return Err(err.into()),
}

Browser

Browser trigger calls reject with JavaScript errors. Preserve the engine-provided code/message when present and show policy failures as permission errors in UI.

Pattern Boundaries

  • For invocation modes and enqueue decisions, prefer iii-core-primitives.
  • For SDK-specific exception classes and syntax, prefer iii-sdk-reference.
  • For workflow-level retry and DLQ design, prefer iii-architecture-patterns.
  • For RBAC policy design and logs/traces around worker failures, use the matching worker docs under engine/src/workers/**/skills.

When to Use

  • Use this skill when the task mentions iii errors, exception handling, failed invocations, timeouts, forbidden calls, retry behavior, or SDK error classes.

Boundaries

  • Do not retry non-idempotent work automatically unless it is enqueued under queue policy.
  • Do not treat RBAC denial as a missing worker.
  • Do not generate removed service APIs or adapter-extension APIs.

Related skills

FAQ

Should iii agents match errors by message text?

No. iii-error-handling requires branching on exact code strings such as function_not_found while keeping engine wire codes separate from SDK-local codes. Message matching alone is unreliable across runtimes.

Which runtimes does iii-error-handling cover?

iii-error-handling covers iii engine and SDK errors across Node, Python, Rust, and browser workers. It maps codes for RBAC denial, timeouts, handler failures, and retryability per runtime surface.

What is function_not_found in iii-error-handling?

function_not_found is emitted by both the iii engine and SDK local dispatch when no registered handler exists. iii-error-handling directs agents to treat it as a missing registration rather than a transient retry case.

Backend & APIsbackendintegrations

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.