Limits of share operator's ref-counting default in RxJS

Direct answer

share multicasts with ref-counting on by default. publish does not ref-count and requires an explicit connect(). shareReplay is a replaying multicast; its ref-counting behavior is configurable and differs from share.

Confirmed facts

• share uses an internal Subject and enables refCount by default. The source is subscribed on the first subscriber and unsubscribed when the subscriber count drops to zero.
• Default share does not replay or buffer values. A subscriber that arrives after emissions have occurred will not receive those prior values.
• With a cold source, a refCount drop to zero tears down the shared subscription, so the next subscriber burst causes the source to be subscribed again and side effects to re-run.

Likely explanation

• A brief unsubscription gap that brings refCount to zero can cause a hot source connection to be torn down and re-established, resulting in lost emissions that occurred while disconnected.
• For finite sources, completion propagates through the shared Subject and triggers teardown. A later subscriber triggers a fresh source subscription rather than receiving the prior completion.
• An error in the source tears down the shared Subject. New subscribers will cause a new subscription unless reset behavior is explicitly configured.

Trade-offs of ref-counting by default

Ergonomic convenience: share starts and stops automatically, so most consumers get a shared cold source without manual connect logic.

Predictability cost: automatic teardown on zero subscribers can restart non-idempotent side effects, lose in-flight emissions during gaps, and surprise developers who expect a persistent hot stream.

Resource usage: ref-counting avoids leaks by unsubscribing when unused, but can cause repeated subscribe work if subscribers churn.

Backward compatibility

Changing the default of share to non-ref-counting, or making publish ref-count by default, would break code that relies on manual connect for long-lived hot streams. Applications that expect publish + connect to stay alive regardless of subscriber count would see premature teardown with ref-counting, and applications that expect share to stay connected would see leaks or unexpected restarts if ref-counting were removed.

Operator separation

The current design keeps the concerns separate: publish for manual connect control, share for automatic ref-counting multicast, and shareReplay for replaying multicast with optional ref-counting. Providing a separate opt-in variant instead of changing defaults preserves existing behavior and lets developers choose the lifetime model explicitly.

Verification steps for this case

1. Create a cold Observable with logs on subscribe, next and complete, apply share, then subscribe and unsubscribe with timed delays to observe connect and disconnect points.
2. Subscribe a second subscriber after the first has unsubscribed and confirm the source subscribe log runs again, demonstrating refCount restart.
3. Subscribe late after emissions have occurred and confirm the late subscriber receives no prior values, distinguishing share from replay variants.

One missing diagnostic detail that changes the recommendation: the RxJS major version installed. Share signature and shareReplay defaults are version-sensitive, so confirm the version before assuming refCount defaults for shareReplay.