Skip to main content

Endpoints

By default, SDKs connect to the cloud instance at s2.dev, and only require an access token to get started, which can be generated from the dashboard. Users who elect to use Private Networking can provide the relevant endpoints as an override when configuring the client. SDKs can also connect to any S2-compatible endpoint, such as s2-lite for local development:
const client = new S2({
	accessToken: "local-token",
	endpoints: {
		account: "http://localhost:8080",
		basin: "http://localhost:8080",
	},
});

Environment Variables

SDKs can read some common configuration keys from environment variables:
VariableDescription
S2_ACCOUNT_ENDPOINTAccount-level API endpoint
S2_BASIN_ENDPOINTBasin-level API endpoint (may include {basin} placeholder for DNS-based routing)

Timeouts

SDKs support configuring connection and request timeouts:
const client = new S2({
	accessToken: token,
	connectionTimeoutMillis: 3000,
	requestTimeoutMillis: 5000,
});
  • Connection timeout: Maximum time to wait for a TCP connection to be established. This is a “fail fast” timeout that aborts slow connections early.
  • Request timeout: Maximum time to wait for a unary (non-streaming) request to complete. For append sessions, this value is also used to determine the SDK-enforced timeout for an individual batch append to be acknowledged.

Retry Behavior

SDKs automatically retry transient failures using exponential backoff with jitter.
const client = new S2({
	accessToken: token,
	retry: {
		maxAttempts: 5,
		minBaseDelayMillis: 100,
		maxBaseDelayMillis: 2000,
	},
});

Append Retry Policy

Retrying appends requires care: if an append succeeds but the acknowledgement is lost, retrying would create duplicate records in a stream. The appendRetryPolicy setting controls how to react in this situation, by treating append retries as a special case.
PolicyBehavior
all (default)Retry all appends. Duplicates are possible on transient failures.
noSideEffectsOnly retry appends that include matchSeqNum, which makes them idempotent.
Using noSideEffects means that, in the event of a failure, the caller will manually need to verify whether or not the append succeeded (e.g., by reading or otherwise inspecting the state of the stream).
To achieve “exactly-once” semantics in single-writer setups, a matchSeqNum precondition can be used when appending. See concurrency control in the API docs.

Configuration Reference

Timeout Settings

SettingDefaultDescription
Connection timeout3 secondsMax time to establish TCP connection
Request timeout5 secondsMax time for request completion

Retry Settings

SettingDefaultDescription
Max attempts3Maximum retry attempts
Min base delay100 msMinimum base delay for exponential backoff
Max base delay1 secondMaximum base delay (actual delay with jitter can be up to 2x)
Append retry policyallHow to handle append retries when duplication is possible