Boundaries

Polling Manager Boundaries

Boundaries define what Polling Manager owns and what it must not own.

Boundary Principle

Polling Manager is infrastructure. It must remain reusable, domain-agnostic, and timer-mechanics-focused.

If domain logic starts migrating into Polling Manager, its core boundary is broken.

Ownership Boundaries

Polling Manager owns

• Keyed task registry and deduplication
• Subscription ref-count lifecycle
• Poll scheduling and overlap control
• Global/per-key pause and resume controls
• Visibility pause behavior when documentRef is provided

Consumers own

• Key composition strategy
• pollFn implementation and data source details
• shouldStop terminal rules
• Mapping raw results into domain/UI actions

Dependency Boundaries

Polling Manager should not import:

• Feature modules (src/modules/**)
• Context and hook layers (src/context/**, src/hooks/**)
• Transport-specific services (src/services/**)
• GraphQL query modules (src/graphql/**)

pollFn is injected by consumers, so transport concerns stay outside manager internals.

Integration Boundaries (Current Phase)

Current phase is infrastructure only:

• Polling Manager implementation and tests are in scope
• Consumer integration (for example LiveStreamRuntime migration) is out of scope

This keeps behavioral changes isolated while locking the infrastructure contract.

API Discipline Boundaries

Must not:

• Reintroduce public unsubscribe(subscriptionId) API
• Treat callback updates as task mutation
• Allow updates to task-defining fields (key, pollFn, intervalMs, shouldStop, pauseWhenHidden)
• Trigger additional immediate polls for later subscribers of an existing key
• Bypass the manager with ad-hoc setInterval loops in consumers where manager usage is intended

For same-key subscriptions, task-defining mismatch must fail fast rather than silently attaching with incompatible assumptions.

Layer Diagram