Please make timeout configurable in render-worker.ts

[e-oz]

Command

build

Description

During pre-rendering, if we need to prerender multiple routes (like 36 routes), pre-rendering fails by timeout.
If I manually modify the timeout in this file, it works fine.
Yes, it takes time, but it is important to pre-render them all for us.

Describe the solution you'd like

Please add an option to angular.json configuration (or some flag, although an option would be much better - fewer dances with builders).

Describe alternatives you've considered

The only alternative right now is to limit the amount of pre-rendered routes.

[alan-agius4]

@e-oz, I am curious to why each route is taking more than 30s to render.

We could potentially increase the timeout, however in general 30s should be more than enough to rendering a single route.

[e-oz]

@alan-agius4 it takes a couple of seconds to render 20 routes.
my theory: some workers are waiting for the initialization because of the max_threads limit, and if at least one of them fails, all the promises fail (because of Promise.all).
This theory comes from practical observations but might be completely wrong.

[alan-agius4]

The initialization phase is not included in this process.

The 30-second limit applies per route and begins as soon as the route rendering starts. It ends as soon as the route finishes rendering, not when it is added to the queue.

If a timeout occurs, it indicates that one or more routes are taking 30 seconds or longer to render.

[e-oz]

All the pages enlisted in routes.txt send just 2 requests to the server, one takes ~150ms, and another takes ~250ms. There are no heavy requests.

Sometimes pre-rendering fails even with 7 routes to pre-render.

The app is zoneless - can it create a situation when renderer can not detect that the page’s rendering is complete?

[alan-agius4]

When using zoneless and server rendering, there are certainly some rough edges. However, I would expect the application to stabilize before time rather than the other way.

Could you provide a reproduction of the issue? Does this behavior persist if the application is configured to use zones instead?

[e-oz]

That’s not a bug report, just a feature request :)
Sorry, we decided to move from SSG to full SSR (because SSG doesn’t seem stable enough yet), so I now have no time to research this topic.
I’m not sure if I should close this feature request - perhaps someone else will find it and decide to continue researching it.
But I don’t mind if you close this issue.

[alan-agius4]

SSG is generally stable. I believe a 30-second rendering timeout is typically sufficient. This has been the standard for several major versions, and this is the first time it's been brought to our attention that it's not enough.

If a page doesn't stabilize within 30 seconds, it's usually an indication of a problem within the app itself. In the past, we've seen timeouts with zone.js, often due to the use of timeouts, intervals, or similar mechanisms, which caused delays in stabilizing the page.

Closing for now, please feel free to open a new issue with a reproduction if you manage to find out the root cause. Thanks.

[uttamughareja]

@alan-agius4 in my case the app is very simple without any complex setTimout or complex computation.

the issue is happening because the backend/api is taking time to return the response.

I also thing 30s per route is fair enough, but it would be helpful if we have option to explicitly control this delay.

[e-oz]

I agree with @alan-agius4 and think that we should try to fix stabilization, not increase the timeout.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}