Profiles·Public

rxjs

semver>=7.0.0 <8.0.0postconditions10functions5last verified2026-04-16coverage score100%

Postconditions — what we check

firstValueFrom · observable-error
error
WhenThe Observable emits an error notification before any value
ThrowsThe error value from the Observable (re-thrown as Promise rejection)
Required handlingCaller MUST wrap in try-catch. Observable errors become Promise rejections. If the Observable may error (network requests, microservice calls, HTTP calls), the error case must be explicitly handled.
costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
Sources[1]
firstValueFrom · empty-completion
error
WhenThe Observable completes without emitting any value and no defaultValue is provided
ThrowsEmptyError: no elements in sequence
Required handlingCaller MUST either provide a defaultValue option to avoid EmptyError, or wrap in try-catch. Use firstValueFrom(obs, { defaultValue: fallback }) to safely handle Observables that may complete without emitting.
costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
Sources[1]
lastValueFrom · observable-error
error
WhenThe Observable emits an error notification at any point
ThrowsThe error value from the Observable (re-thrown as Promise rejection)
Required handlingCaller MUST wrap in try-catch. Observable errors become Promise rejections. NestJS microservice calls (client.send()), Angular HttpClient calls, and other Observable-based APIs can error, and those errors propagate as rejections.
costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
Sources[2]
lastValueFrom · empty-completion
error
WhenThe Observable completes without emitting any value and no defaultValue is provided
ThrowsEmptyError: no elements in sequence
Required handlingCaller MUST either provide a defaultValue option to avoid EmptyError, or wrap in try-catch. Use lastValueFrom(obs, { defaultValue: fallback }) to safely handle Observables that may complete without emitting.
costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
Sources[2]
forEach · foreach-observable-error
error
WhenThe Observable emits an error notification at any point during iteration
ThrowsThe error value from the Observable (re-thrown as Promise rejection)
Required handlingCaller MUST wrap forEach() in try-catch. Observable errors become Promise rejections. NestJS and Angular code that uses forEach() to process streams (e.g., database cursor iteration, microservice response streaming) will throw unhandled rejections if not wrapped.
costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
Sources[3]
forEach · foreach-callback-throws
error
WhenThe next callback provided to forEach() throws an exception (e.g., JSON.parse failure, type error)
ThrowsThe exception thrown by the callback. The Observable is unsubscribed and the Promise rejects with the callback's exception. Remaining stream values are silently dropped.
Required handlingCaller MUST wrap forEach() in try-catch. Callback exceptions unsubscribe the Observable mid-stream, dropping remaining values. Partial processing causes data inconsistency if the callback had side effects (e.g., DB writes). Ensure the callback itself handles errors internally or wrap the entire forEach() call.
costmediumin prodsilent failureusers seelost datavisibilitysilent
Sources[3]
toPromise · topromise-observable-error
error
WhenThe Observable emits an error notification at any point
ThrowsThe error value from the Observable (re-thrown as Promise rejection)
Required handlingCaller MUST wrap toPromise() in try-catch. Despite being deprecated, toPromise() is still used in thousands of NestJS and Angular apps via patterns like: await httpClient.get(url).toPromise(). Missing try-catch causes unhandled rejections that crash the async function or request handler.
costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
Sources[4]
toPromise · topromise-undefined-on-empty
warning
WhenThe Observable completes without emitting any value
Returnsundefined (silently resolves to undefined instead of throwing EmptyError)
Required handlingCaller MUST null-check the resolved value before use, or migrate to lastValueFrom() which explicitly throws EmptyError for empty Observables. Common crash pattern in Angular services: const data = await obs$.toPromise(); data.items.forEach() — crashes with TypeError when Observable emits nothing.
costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
Sources[4]
fromFetch · fromfetch-no-ok-check
error
WhenThe fromFetch() Observable emits a Response with response.ok === false (HTTP 4xx/5xx status codes) but the caller does not check response.ok and proceeds to use the response body as if the request succeeded. Common pattern: await firstValueFrom(fromFetch('/api/data').pipe(switchMap(r => r.json()))) without checking r.ok first — a 500 response silently returns error body as data.
ThrowsDoes NOT throw. The Observable emits the Response as a next() value regardless of HTTP status. The error is silent — response.ok is false, response.status is 4xx/5xx, but no Observable error notification is raised unless the caller explicitly throws one.
Required handlingCaller MUST check response.ok before consuming the response body: fromFetch('/api/users').pipe( switchMap(response => { if (response.ok) { return response.json(); } throw new Error(`HTTP Error: ${response.status}`); }) ) Not checking response.ok causes 4xx/5xx errors to silently appear as successful data responses, corrupting application state. This is the most common fromFetch misuse pattern.
costhighin prodsilent failureusers seelost datavisibilitysilent
Sources[5][6]
fromFetch · fromfetch-network-error-unhandled
error
WhenThe underlying native fetch() rejects with a TypeError (network unreachable, CORS policy violation, invalid URL, DNS resolution failure). The fromFetch() Observable propagates this as an Observable error notification. When subscribed via firstValueFrom(fromFetch(...)) without try-catch, it becomes an unhandled Promise rejection. Common in Node.js backends using fromFetch for service-to-service calls.
ThrowsTypeError: Failed to fetch (browser) or TypeError: fetch failed (Node.js). Propagated via subscriber.error(err) from the .catch(handleError) in fromFetch source.
Required handlingCaller MUST handle network errors via catchError() operator or try-catch: try { const response = await firstValueFrom(fromFetch('/api/data')); if (!response.ok) throw new Error(`HTTP ${response.status}`); return await response.json(); } catch (err) { // TypeError for network failures, custom Error for non-2xx } Network errors cause unhandled promise rejections in async functions using await firstValueFrom(fromFetch(...)) without try-catch.
costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
Sources[5][7]

Sources

Every postcondition cites at least one of these. Numbered to match the footnotes above.

Need a different package?

Request a profile