-
Notifications
You must be signed in to change notification settings - Fork 25.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(http): delay accessing pendingTasks.whenAllTasksComplete #49784
Conversation
4171dd0
to
78c32f4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the fixes @alan-agius4 👍
I've left a minor comment, but let's address it in a followup PR (we can proceed with the merge using the current state).
Another quick question (also for a followup): would it be possible to create a couple test cases for this change, so that we don't regress in the future?
Thank you.
const pendingTasksPromise = pendingTasks.whenAllTasksComplete; | ||
|
||
Promise.allSettled([isStablePromise, pendingTasksPromise]).then(() => { | ||
isStablePromise.then(() => pendingTasks.whenAllTasksComplete).then(() => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I think it'd be great to add a comment to mention:
- why we do the nesting of promises
- why the
APP_INITIALIZER
token is used (and the fact that we don't delay the bootstrap, we just subscribe sooner)
Current in the `InitialRenderPendingTasks` when the `collection` size is 0 a new promise is created a the status is changed to completed. This causes the promise that is created during the class initialization phase to never be resolved which causes SSR to hang indefinitely.
Accessing `pendingTasks.whenAllTasksComplete` too early causes the `InitialRenderPendingTasks` to return a resolved promise too early. This commit changes the way we access `whenAllTasksComplete` to only happen when the application is stabilized.
78c32f4
to
2e30f1b
Compare
FYI I've pushed a rebase to resolve the merge conflict, which happened around the imports section (no actual conflicts in the logic itself). We can reuse previous g3 presubmit (which was "green") and proceed with the merge. |
This PR was merged into the repository by commit f9b821f. |
Accessing `pendingTasks.whenAllTasksComplete` too early causes the `InitialRenderPendingTasks` to return a resolved promise too early. This commit changes the way we access `whenAllTasksComplete` to only happen when the application is stabilized. PR Close #49784
Accessing `pendingTasks.whenAllTasksComplete` too early causes the `InitialRenderPendingTasks` to return a resolved promise too early. This commit changes the way we access `whenAllTasksComplete` to only happen when the application is stabilized. PR Close #49784
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
fix(http): delay accessing
pendingTasks.whenAllTasksComplete
Accessing
pendingTasks.whenAllTasksComplete
too early causes theInitialRenderPendingTasks
to return a resolved promise too early. This commit changes the way we accesswhenAllTasksComplete
to only happen when the application is stabilized.fix(core): resolve
InitialRenderPendingTasks
promise on completeCurrent in the
InitialRenderPendingTasks
when thecollection
size is 0 a new promise is created a the status is changed to completed. This causes the promise that is created during the class initialization phase to never be resolved which causes SSR to hang indefinitely.