fix(pump): preserve factory arity 2 so per-pumpGroup state managers are honored

[jbiskur]

Summary

createPostgresPumpStateManagerFactory returned a function with a default value on pumpGroup:

return (flowType: string, pumpGroup: string = DEFAULT_PUMP_GROUP) => …

JavaScript's Function.prototype.length skips parameters with default values, so this function's .length === 1. PathwayPump's arity check at pathway-pump.ts:239:

if (this.stateManagerFactoryArity <= 1) {
  // legacy fallback — call with flowType only
  return (this.stateManagerFactory as unknown as (flowType: string) => PumpStateManager)(flowType)
}

…treats the library's own factory as a "legacy" single-arg factory and invokes it with flowType only. The defaulted pumpGroup becomes "default" for every pump, so two pumps on the same flowType with different pumpGroup values share a single PostgresPumpStateManager keyed (flowType, "default").

Production evidence

Verified in service-tenant-store-api@1.6.3 (which registers tenant.0/api-key.used.0 with pumpGroup: "hot" and 12 other tenant.0 event types under the implicit default group):

• _pathway_pump_state contained only one row for tenant.0 (the default group). The (tenant.0, hot) row was never inserted, even though the schema has PRIMARY KEY (flow_type, pump_group) and supports it.
• The default row's event_id was verifiably an api-key.used.0 event id (the only event type with activity in that bucket). The default pump — whose eventTypes filter excludes api-key.used.0 — was advancing past api-key.used.0 events because its state manager was shared with the hot pump.
• The hot pump silently no-op'd: shared cursor advanced past its events, fetches returned empty batches, no acks, no setState calls, no row.

Fix

Drop the default value on the second parameter so .length === 2. Move the runtime fallback inside the body:

-  return (flowType: string, pumpGroup: string = DEFAULT_PUMP_GROUP): PumpStateManager => {
-    return new PostgresPumpStateManager(adapter, flowType, pumpGroup, table)
+  return (flowType: string, pumpGroup: string): PumpStateManager => {
+    return new PostgresPumpStateManager(adapter, flowType, pumpGroup ?? DEFAULT_PUMP_GROUP, table)
   }

PathwayPump now takes the non-legacy branch and forwards both (flowType, pumpGroup) to the factory. Each pair gets its own state manager and its own row in _pathway_pump_state. The ?? DEFAULT_PUMP_GROUP inside the body preserves runtime safety for any external caller passing undefined — same observable behaviour as before for legacy callers.

Tests

• tests/postgres-pump-state.test.ts — new step factory function declares arity 2 …. Asserts factory.length === 2. This is the direct regression catch.
• tests/pathway-pump.test.ts — new step arity-2 state factory receives both (flowType, pumpGroup) so each group gets its own manager. Constructs a PathwayPump with an arity-2 mock factory, runs startPumpForGroup for hot and default groups, asserts the factory was called with [("orders", "hot"), ("orders", "default")], two distinct managers were instantiated, and no legacy-arity warning was emitted.

The existing legacy test ("legacy single-arg state factory is accepted with a deprecation warning") still passes — backward compatibility for genuinely arity-1 user-provided factories is preserved.

Test plan

• deno fmt --check clean
• deno lint clean
• deno check src/mod.ts clean
• deno test -A --ignore=tests/postgres-*.test.ts — 15 passed (140 steps)
• Postgres tests after this lands — covered by the existing test:postgres task.

Risk notes

• Tiny blast radius. One-line library change. The factory's runtime semantics for any well-formed caller are identical.
• Existing user factories with arity 1 continue to work unchanged via the legacy fallback path.
• No data migration. The composite-PK migration on _pathway_pump_state already shipped in 2.4.0. New (flow_type, pump_group) rows will be inserted on first hot-pump setState per consumer service after they bump.

Related fragments

• f98a5d4b-… — original 2.4.0 pumpGroup release.
• c2ee688f-… — 2.4.1 pulse pathwayId fix.
• f7736088-… — service-tenant-store-api 1.6.0 → 1.6.3 production rollout (same service that surfaced this bug).