Resonate Defaults

Resonate Defaults

Overview

Use this skill when an agent (or user) needs to answer a "what is the default for X in Resonate?" question. The canonical reference page lives at:

• https://docs.resonatehq.io/reference/defaults

That page is the single source of truth — every value below mirrors it. If the canonical page and this skill disagree, the canonical page wins and this skill is stale.

The skill carries a quick-lookup table so an agent can answer common questions in one hop. For anything not in the table, read the canonical page or the source files listed under Source-of-truth files.

When to use this skill

Trigger this skill when the question is about a default value, especially:

• "What does ctx.run retry by default?"
• "What is the default timeout for a durable function?"
• "What is the default ttl / group / target?"
• "What does Exponential() default to without arguments?"
• "What is RESONATE_URL if I do not set it?"
• "What is the default Resonate server port / log level / storage backend?"
• Any "I called the constructor / Options(...) / Exponential(...) with no args — what did I get?"

If the question is how to configure something (versus what the default is), reach for the relevant resonate-basic-* or resonate-server-deployment skill instead.

Source-of-truth files

When the canonical page does not answer the question, read these files directly. Do not guess or deflect.

TypeScript SDK (resonatehq/resonate-sdk-ts)

• src/options.ts — per-call Options defaults (timeout, target, tags, version, nonRetryableErrors, etc.)
• src/retries.ts — Exponential, Constant, Linear, Never constructor defaults
• src/resonate.ts — init defaults (group, ttl, pid, verbose, logLevel, prefix, url resolution)
• src/network/http.ts — HttpNetwork defaults (request timeout, URL fallback)
• src/context.ts — runtime resolution that picks Exponential for regular functions vs Never for generator functions

Python SDK (resonatehq/resonate-sdk-py)

• resonate/options.py — Options dataclass defaults
• resonate/retry_policies/exponential.py, constant.py, linear.py, never.py — retry-policy constructor defaults
• resonate/resonate.py — init defaults (group, ttl, pid, log_level, env-var resolution)
• resonate/processor.py — workers cap (min(32, workers or os.cpu_count() or 1))

Rust SDK (resonatehq/resonate-sdk-rs)

• resonate/src/options.rs — Options struct defaults (note: no per-call retry_policy field)
• resonate/src/resonate.rs — init defaults (group, ttl, pid, env-var resolution)

Go SDK (resonatehq/resonate-sdk-go)

Tagged 0.1.0 (the tag has no v prefix — go get github.com/resonatehq/resonate-sdk-go@0.1.0 to pin it; @latest does not resolve to the tag). Values verified against the 0.1.0 tag source. The canonical doc-page summary lives in the Go SDK skill guide § Defaults.

• resonate.go — Config defaults (TTL 60s, AsyncHeartbeat, NoopEncryptor, empty Prefix), New network resolution (URL → Network → RESONATE_URL → ErrNetworkRequired), DefaultTopLevelTimeout, DefaultRetryPolicy
• context.go — child-call defaults (DefaultChildTimeout), RunOpts/RPCOpts/PromiseOpts/DetachedOpts
• the retry-policy types (ConstantRetry, LinearRetry, ExponentialRetry, NoRetry) and NewNonRetryable
• httpnet/http.go — HTTPOptions{Group} (the default group is "default"); groups are set on the transport, not on Config
• promises.go / schedules.go — the direct Promises / Schedules sub-clients (PromiseCreateOptions, ScheduleCreateOptions, DefaultTopLevelTimeout as their timeout fallback)

Server (resonatehq/resonate)

Server flag defaults are mirrored on the operator-facing page https://docs.resonatehq.io/deploy/run-server#configuration until iter-65 lands file:line citations from the server crate.

Quick-lookup table

The values below mirror the canonical page. If you cite from this table, the value is current as of the canonical page's last update; if the question is high-stakes, double-check by visiting the canonical URL.

Retry policies (per-call options)

Both TS and Py compute the n-th Exponential delay as min(delay * factor^attempt, maxDelay); Linear is delay * attempt; Never is 0 on attempt 0 and null/None after. Go's retry policies ARE exposed (unlike Rust) as the ConstantRetry / LinearRetry / ExponentialRetry / NoRetry structs implementing resonate.RetryPolicy, and Go's DefaultRetryPolicy is ExponentialRetry{MaxAttempts: 3, Base: 100ms, Max: 30s, Jitter: true} — a bounded 3-attempt default, the sharpest cross-SDK asymmetry (see below). Go durations are native time.Duration, never raw ms/sec.

ctx.run / per-call Options defaults

The short answer to "what does ctx.run retry by default in the TypeScript SDK?" is Exponential() (1 s base, ×2 factor, 30 s cap, effectively unbounded retries) for regular async functions, and Never() for generator functions. In Go the answer is different: DefaultRetryPolicy is bounded to 3 attempts (ExponentialRetry{MaxAttempts: 3, Base: 100ms, Max: 30s, Jitter: true}).

Init defaults (new Resonate() / Resonate() / Resonate::local() / resonate.New(Config{}))

Environment variables

Go reads ONLY RESONATE_URL from the environment. It does not consult RESONATE_HOST / RESONATE_PORT / RESONATE_SCHEME / RESONATE_TOKEN / RESONATE_PREFIX. Token, prefix, and group are set explicitly on Config (or, for group, on the transport). The single env hook is RESONATE_URL; if it (and Config.URL / Config.Network) is unset, resonate.New returns ErrNetworkRequired rather than falling back to localhost.

Server flag defaults (Rust binary)

Critical cross-SDK asymmetries

The defaults look like they line up across SDKs. They do not. Flag these explicitly when answering:

• Time units differ. TypeScript expresses durations in milliseconds. Python expresses durations in seconds. Rust is mixed — Options.timeout is a Duration, but ttl is u64 milliseconds. Go uses native time.Duration everywhere (24 * time.Hour, 100 * time.Millisecond) — never a raw number. A naive copy-paste between SDKs is almost always wrong.
• Go's default retry policy is BOUNDED. TS and Py default to effectively-unbounded retries (Number.MAX_SAFE_INTEGER / sys.maxsize). Go's DefaultRetryPolicy caps at MaxAttempts: 3. A Go workflow gives up after 3 attempts where the TS/Py equivalent would retry almost forever. This is load-bearing when porting — do not assume Go inherits the unbounded default.
• Per-call retry policy: Go HAS one, Rust does NOT. Go's RunOptions/RunOpts carry a RetryPolicy field (like TS/Py); Rust has no per-call retry policy (server-side --tasks-retry-timeout governs it). Go is the TS/Py side of this split, not the Rust side.
• Go's 0.1.0 tag shipped direct Promises() and Schedules() sub-clients. r.Promises().Resolve/Reject/Cancel/Create/Get and r.Schedules().Create/Get/Delete are real methods now — prefer them over the CLI, the server HTTP API, or the low-level r.Sender().PromiseSettle (that low-level path still requires manual JSON→base64→quoted-string Value encoding; the sub-client methods do it for you via the instance's Codec). The remaining Go gap is a top-level resonate.Schedule(id, cron, fn, args) convenience wrapper that dispatches a registered function by name on a cron — Python, TypeScript, and Rust all have one; Go's Schedules().Create only creates the underlying cron-fired promise, so dispatching a registered function through it means setting the resonate:target tag and {"func":...,"args":...} param shape by hand.
• Options.timeout envelope. TypeScript and Rust default to 24 h. Python defaults to 1 year (31_536_000 seconds). Same field, drastically different upper bound.
• ttl unit and value. TypeScript and Rust = 60_000 ms (= 60 s). Python = 10 sec. Same name, different unit and different value.
• Retry-policy time units. TS retry-policy parameters are in milliseconds; Python's are in seconds. The curve shape is identical; the numbers are not.
• Rust has no per-call retry_policy. Retry cadence for Rust workers is determined server-side by the --tasks-retry-timeout flag, not by anything on Options. This is a known asymmetry — do not assume Rust mirrors TS/Py here.
• Worker concurrency cap. Only Python imposes one (min(32, workers or os.cpu_count() or 1)). TypeScript runs on the Node/Bun event loop; Rust runs on the user-supplied Tokio runtime. Neither caps task execution at the SDK layer.

Don't deflect — read the source

If a default is not in this skill and not on the canonical page, the correct response is to read the source file listed under Source-of-truth files. Do not answer with:

• "check the SDK source"
• "see the GitHub repo"
• "consult the SDK documentation"

Those answers are the deflection pattern this skill exists to eliminate. The links above are the source. Fetch them and read.

If the canonical page itself is missing a value an agent needs, that is a gap in the canonical page — file it, do not paper over it.

Verifying the answer

Two quick checks before you cite a number:

1. Unit check. If the SDK is Python and the number is in milliseconds, you are wrong. If the SDK is TypeScript and the number is in seconds, you are wrong (Rust Duration is the only place this gets nuanced).
2. Asymmetry check. Before generalising a TS default to Python or Rust, re-read the asymmetries section above. Most cross-SDK questions have at least one trap.