This issue comes out of a cross-SDK conformance audit comparing every Sendspin client/server implementation (aiosendspin, sendspin-cli, sendspin-cpp, sendspin-dotnet, sendspin-go, sendspin-js, sendspin-jvm, sendspin-rs, SendspinKit) against the spec. sendspin-cpp is treated as the reference implementation throughout — it most closely matches the spec's language and is the only SDK that runs on the constrained-embedded target the spec was originally written for.
static_delay_ms is a small but spec-mandatory field, and persistence
is broken almost everywhere: only sendspin-cpp and sendspin-cli
persist the value. Two SDKs (sendspin-rs and SendspinKit) parse
the value but never apply it in playback — the highest-severity bug
the audit found (already filed against those SDKs). sendspin-cpp is
the reference here: SendspinPersistenceProvider for storage,
sync_task.cpp:231 subtracts effective_static_delay_ms × US_PER_MS
from converted timestamps, and set_static_delay_adjustable(bool)
supports per-output values.
1. Restate persistence as a recommended SDK feature
Today the spec text "Clients must persist static_delay_ms locally"
reads as a requirement on the device. In practice the SDK is where
that persistence has to live. Add:
Client SDKs SHOULD provide a persistence hook for static_delay_ms
(file, key-value, or callback) so applications need not
re-implement storage.
Point to sendspin-cpp's SendspinPersistenceProvider as the
reference shape.
2. Make range validation MUST
Clients MUST clamp incoming static_delay_ms values to 0–5000 and
MUST treat any out-of-range value as a protocol error to log.
sendspin-cpp enforces 0–5000 strictly; sendspin-cli silently
coerces negatives to positives; sendspin-js clamps; the rest don't
check at all. A misbehaving server or local config could supply
out-of-range values today.
Source audit doc: docs/static-delay.md
Full audit branch: claude/stream-sync-correction-sdks-AWoNC
Per-SDK digest: sdk-issues digest
This issue comes out of a cross-SDK conformance audit comparing every Sendspin client/server implementation (
aiosendspin,sendspin-cli,sendspin-cpp,sendspin-dotnet,sendspin-go,sendspin-js,sendspin-jvm,sendspin-rs,SendspinKit) against the spec.sendspin-cppis treated as the reference implementation throughout — it most closely matches the spec's language and is the only SDK that runs on the constrained-embedded target the spec was originally written for.static_delay_msis a small but spec-mandatory field, and persistenceis broken almost everywhere: only
sendspin-cppandsendspin-clipersist the value. Two SDKs (
sendspin-rsandSendspinKit) parsethe value but never apply it in playback — the highest-severity bug
the audit found (already filed against those SDKs).
sendspin-cppisthe reference here:
SendspinPersistenceProviderfor storage,sync_task.cpp:231subtractseffective_static_delay_ms × US_PER_MSfrom converted timestamps, and
set_static_delay_adjustable(bool)supports per-output values.
1. Restate persistence as a recommended SDK feature
Today the spec text "Clients must persist
static_delay_mslocally"reads as a requirement on the device. In practice the SDK is where
that persistence has to live. Add:
Point to
sendspin-cpp'sSendspinPersistenceProvideras thereference shape.
2. Make range validation MUST
sendspin-cppenforces 0–5000 strictly;sendspin-clisilentlycoerces negatives to positives;
sendspin-jsclamps; the rest don'tcheck at all. A misbehaving server or local config could supply
out-of-range values today.
Source audit doc:
docs/static-delay.mdFull audit branch:
claude/stream-sync-correction-sdks-AWoNCPer-SDK digest: sdk-issues digest