Checking algorithm step null-ness vs checking active is not equivalent, unfortunately. You can have a Subscriber whose algorithms are null (for example, if nobody provided a complete() handler) but is still active. So if Subscriber#complete() only checked active, it will try and execute the complete steps, which may be null.

Does that make sense?

@domfarolino

So if Subscriber#complete() only checked active, it will try and execute the complete steps, which may be null.

By subscribe to an Observable concept, the steps 2 lets a new internal observer and it will be used to initialize subscriber in the step 5.

https://wicg.github.io/observable/#observable-subscribe-to-an-observable

2. Let internal observer be a new internal observer.

---

5. Let subscriber be a new [Subscriber]> (https://wicg.github.io/observable/#subscriber), initialized as:

   • next algorithm
     • internal observer’s next steps
   • error algorithm
     • internal observer’s error steps
   • complete algorithm
     • internal observer’s complete steps
       ....

But internal observer has initial value but I read they does not means null:

https://wicg.github.io/observable/#internal-observer

An internal observer is a struct with the following items:
next steps
An algorithm that takes a single parameter of type any. Initially, these steps do nothing.
error steps
An algorithm that takes a single parameter of type any. Initially, the default > error algorithm.
complete steps
An algorithm with no parameters. Initially, these steps do nothing.

From these definitions of the current spec and other parts, I seem next/error/complete algorithm would not be null without steps in close a subscription concept.

From these definitions of the current spec and other parts, I seem next/error/complete algorithm would not be null without steps in close a subscription concept.

Looks like you're right, good catch! Feel free to send a PR my way to clean this up in the spec, if you'd like.