Keep optimistic usage updates in track when the replicator is not ready

[ryanechternacht]

Problem

track enqueues the event and then optimistically bumps the cached company metric via updateCompanyMetrics. That second step was gated on datastreamClient.isConnected(), which in replicator mode is the health endpoint's ready field. When a customer's Schematic account is closed or Schematic is unreachable, the replicator stays up with its Redis cache intact but reports ready: false. Flag checks keep evaluating from that cache, but usage stopped counting locally, so numeric limits never moved for as long as the replicator was not ready. The event was still enqueued to the API either way.

What I found

History of the gate:

• Node got it in add wasm rulesengine #59 (add wasm rulesengine) as body.company && this.useDataStream() && this.datastreamClient!.isConnected() with the comment "if available and connected". Later edits (Chris/schy 380 sdk entitlement usage does not update from datastream #127, credit lease SDK primitives: check / trackWithReservation / prewarm #121, Close the lease-client gaps the port reviews found #194) carried the condition forward unchanged; Close the lease-client gaps the port reviews found #194 added the updateMetrics flag. No PR discussion or commit message explains the connected check.
• It is a port of the Go SDK. Go added optimistic metric updates in Chris/sch 3745 optimistic metric updates schematic-go#73 (July 2025) as body.Company != nil && c.datastreamConnected. At that point useDataStream() itself returned datastreamConnected, so "connected" was simply the signal that the DataStream was in use. 🌿 Fern Regeneration -- February 25, 2026 #82 split it mechanically into useDataStream() && IsConnected(). Replicator mode came later (SCHY-148 Use miniflare to test builds in a cloudflare environment #88, September 2025) and redefined IsConnected() as replicator readiness without revisiting this call site. Go still has the same gate in emitTrack.

Correctness checks:

• Missing cache: updateCompanyMetrics reads the company from the cache and returns without writing if it is not there, so a not ready replicator with an empty or partial cache is a no-op. The test covers this.
• Double counting: the bump is a local prediction. Full company messages overwrite the cached company, and partial messages upsert metrics by (event subtype, period, month reset) with the server's absolute value, so whatever the server sends next replaces the local figure instead of adding to it. While the replicator is not ready nothing is sent, so there is no race with a server update. When it recovers, its resync rewrites companies with server values. Duplicate events are already handled separately: trackWithReservation passes updateMetrics = false when the settle did not land locally (Close the lease-client gaps the port reviews found #194).

So I found no correctness reason for the gate.

One related issue this does not change: updateCompanyMetrics rewrites the company and its lookup keys with the SDK's cacheTTL (24 hours by default), while the replicator writes them with no TTL by default. That already happens today whenever track runs with the replicator ready, including for events that match no metric (the company is rewritten regardless). With this change it can also happen while the replicator is not ready, and during an outage longer than cacheTTL, a company that was tracked and then went idle for cacheTTL would drop out of Redis until the replicator resyncs. I'd suggest a follow-up so the metric write in replicator mode keeps the existing expiry and skips the write when no metric matched.

Change

The isConnected() condition is removed from the metric update in emitTrack, so the local update runs whenever a DataStream client exists, in both modes. In WebSocket mode a disconnected client also keeps evaluating cached companies in checkFlag, so skipping the bump there would under count in the same way. The cache is the SDK's own in that mode, so the TTL point above does not apply.

Test

New tests/unit/replicator/track-not-ready.test.ts (and a .fernignore entry for the directory). It uses a real DataStream client in replicator mode, the real WASM rules engine, and the in-memory fake Redis seeded the way the replicator writes it (snake_case JSON under versioned keys). fetch is stubbed so the health endpoint returns { ready: false, cache_version: "v-test" }.

• track with quantity 2 moves the cached api_call metric from 3 to 5.
• A flag gated on api_call >= 5 evaluates false, stays false after one track, and flips to true after the second, with the API mocked to fail.
• Tracking a company that is not cached leaves Redis unchanged.

The first two fail on main and pass with this change. yarn build and yarn test pass (101 suites; the Redis integration suite is skipped locally without TEST_REDIS_URL).

This branch and #201 each add the same tests/unit/replicator/ line to .fernignore at the same spot, so they merge cleanly in either order.

🤖 Generated with Claude Code