Skip to content

fix(@angular/ssr): destroy platform when request is aborted during rendering - #34568

Open
alan-agius4 wants to merge 1 commit into
angular:mainfrom
alan-agius4:fix/ssr-abort-destroy-platform
Open

alan-agius4 wants to merge 1 commit into
angular:mainfrom
alan-agius4:fix/ssr-abort-destroy-platform

Conversation

@alan-agius4

Copy link
Copy Markdown
Collaborator

Previously, aborting request.signal during server-side rendering caused AngularServerApp.handle() to reject via promiseWithAbort, while renderAngular() continued running in the background until whenStable() completed (or leaked the platform if a pending task never resolved).

This commit forwards request.signal into renderAngular() so that aborting an in-flight request destroys the underlying PlatformRef, cancels any pending render timer, and exits cleanly. Additionally, promiseWithAbort() now attaches rejection handlers to the underlying promise even when the signal is already aborted to avoid unhandled promise rejections.

Closes #34567

@alan-agius4 alan-agius4 added the target: patch This PR is targeted for the next patch release label Oct 28, 2026
@alan-agius4
alan-agius4 requested a review from dgp1130 October 28, 2026 13:51
@alan-agius4 alan-agius4 added the action: review The PR is still awaiting reviews from at least one requested reviewer label Oct 28, 2026

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces support for aborting the SSR rendering process using an AbortSignal across AngularNodeAppEngine, AngularAppEngine, and AngularServerApp. When a request is aborted, the underlying Angular platform is destroyed to halt any in-progress rendering, and a DOMException with an 'AbortError' is thrown. The feedback suggests introducing an isDestroyed guard flag in renderAngular to prevent redundant platform destruction when destroy() is called multiple times, and simplifying the catch block by reusing this updated destroy() function.

Comment thread packages/angular/ssr/src/utils/ng.ts
Comment thread packages/angular/ssr/src/utils/ng.ts
@MeAkib

This comment was marked as resolved.

…ndering

Previously, aborting `request.signal` during server-side rendering caused
`AngularServerApp.handle()` to reject via `promiseWithAbort`, while
`renderAngular()` continued running in the background until `whenStable()`
completed (or leaked the platform if a pending task never resolved).

This commit forwards `request.signal` into `renderAngular()` so that aborting
an in-flight request destroys the underlying `PlatformRef`, cancels any
pending render timer, and exits cleanly. Additionally, `promiseWithAbort()`
now attaches rejection handlers to the underlying promise even when the
signal is already aborted to avoid unhandled promise rejections.

Closes angular#34567
@alan-agius4
alan-agius4 force-pushed the fix/ssr-abort-destroy-platform branch from d079bbc to 322f09f Compare October 28, 2026 14:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

action: review The PR is still awaiting reviews from at least one requested reviewer area: @angular/ssr target: patch This PR is targeted for the next patch release

Projects

None yet

Development

Successfully merging this pull request may close these issues.

@angular/ssr: an aborted request rejects handle() but the render keeps running

2 participants