Describe the bug
After enabling logging for notifications on stopped observables with config.onStoppedNotification I noticed that zip() sometimes throws an error which can't be delivered anymore in case the observable gets closed from within the next handler.
Firefox: TypeError: buffers is null
Chrome: TypeError: Cannot read properties of null (reading 'some')
The error originates from here:
|
if (buffers.some((buffer, i) => !buffer.length && completed[i])) { |
Expected behavior
I would not expect this to happen. I think this case should be handled internally.
Reproduction code
import { NEVER, concat, config, first, of, zip } from 'rxjs';
config.onStoppedNotification = (notification) => {
if (notification.kind === 'E') {
throw notification.error;
}
};
const source$ = concat(of(1), NEVER);
zip(source$).pipe(first()).subscribe();
Reproduction URL
https://stackblitz.com/edit/rxjs-qxrbts?devtoolsheight=60&file=index.ts
Version
7.4.0
Environment
I discovered this in an Angular App (v13.1) which also uses NgRx (v13) but I guess it's not relevant for this issue.
Additional context
I think adding a simple check if buffers is already null before calling buffers.some() should fix the issue. I would be happy to provide a PR with this fix.
Describe the bug
After enabling logging for notifications on stopped observables with
config.onStoppedNotificationI noticed thatzip()sometimes throws an error which can't be delivered anymore in case the observable gets closed from within the next handler.Firefox:
TypeError: buffers is nullChrome:
TypeError: Cannot read properties of null (reading 'some')The error originates from here:
rxjs/src/internal/observable/zip.ts
Line 91 in 081ca2b
Expected behavior
I would not expect this to happen. I think this case should be handled internally.
Reproduction code
Reproduction URL
https://stackblitz.com/edit/rxjs-qxrbts?devtoolsheight=60&file=index.ts
Version
7.4.0
Environment
I discovered this in an Angular App (v13.1) which also uses NgRx (v13) but I guess it's not relevant for this issue.
Additional context
I think adding a simple check if
buffersis already null before callingbuffers.some()should fix the issue. I would be happy to provide a PR with this fix.