fix(ingest): avoid re-ingesting 10s every cron cycle for single-instance jetstream
@atcute/jetstream rolls the cursor back 10s on first connect when given an
array url, to absorb clock skew across a randomly-selected pool of
instances. It is meant to fire once per session. But contrail's cron
ingestion rebuilds the JetstreamSubscription every cycle, so for a
single-instance config that "first-connect" rollback fires every tick and
redundantly re-delivers the last 10s of events each cycle.
Add a jetstreamUrlOption(jetstreams) helper in contrail-base that maps the
configured list onto @atcute's url shape by topology:
- one instance -> a string (one fixed instance, no skew, no rollback)
- a real pool (2+) -> an array (cross-instance rollback preserved)
Applied at both construction sites (the cron ingestEvents path and the
runPersistent daemon). Setting two jetstreams does not sidestep this: an
array keeps the per-cycle rollback, and with genuine cross-instance skew
that rollback is then actually needed. A string for the single-instance
case is the only shape that removes the redundant re-ingest.
Also fix a misleading per-cycle reconnect log that claimed every reconnect
picks a URL at random and rolls back 10s, which is only true for a
multi-instance pool. The warning is now gated on urls.length > 1 and
reports the actual rolled_back value; single-instance reconnects log at
info level.
Tests: a helper unit test (single->string, pool->array, empty->empty), an
ingestEvents wiring test, and a characterization test that drives the real
JetstreamSubscription (mocking only the injected socket) to pin the
array-rolls-back / string-does-not behavior the fix relies on, so a future
@atcute change fails loudly here.
authored by