stopping the request during the first page view is breaking initialization

[elevatebart]

Environment

• Operating System: Darwin
• Node Version: v22.10.0
• Nuxt Version: 3.15.4
• CLI Version: 3.21.1
• Nitro Version: 2.10.4
• Package Manager: npm@10.9.0
• Builder: -
• User Config: modules, target, image, sitemap, app, css, content, devServer, features, vue, vite, gtm, runtimeConfig, nitro, routeRules, build, optimization, multiCache, aos, devtools, compatibilityDate
• Runtime Modules: @nuxt/devtools@2.1.0, @nuxt/image@1.9.0, nuxt-multi-cache@3.4.0, vue3-carousel-nuxt@1.1.5, nuxt-lazy-hydrate@1.0.0, nuxt-aos@1.2.5, @zadigetvoltaire/nuxt-gtm@0.0.13, @nuxtjs/sitemap@7.2.5, @nuxtjs/robots@5.2.2, @nuxt/content@3.1.1
• Build Modules: -

Version

v3+

Reproduction

https://kestra.io

Description

When DB init takes more that 100s, the Cloudflare timeout takes on and returns.
I hope the query finishes but it's hard to make sure of.

Would it be better to do this init as a "fire and forget"?
We could send a flag with each dataset saying "initializing" so we can tell users what is happening and still communicate a progress.
Even better we could have a ProgressBar component telling where we are.

Additional context

No response

Logs

[elevatebart]

If we remove these 3 lines, the init will continue but h3 will return to the users browser early with no values. Hence, no timeout.
Because there would be no value, users would wonder what is happening, why they see an error/no values.

To mitigate that, we could have another API returning the status of the database compared to the dump.

We could even have a WebSocket based progress-bar component.

[elevatebart]

Hi Team,

I have narrowed the issue down to a simple and reliable way to reproduce the issue on cloudflare:

There is only one request that initializes a collection in the database.
If that request is cancelled, the system is blocked... forever.

And to cancel a request, one only needs to close the tab or hit "stop" in chrome.

To reproduce, use a significant collection. It will give you more time to hist stop later.
During the first request to te collection, click stop.
Now check the Database:

• ready is 0,
• values are not being inserted anymore,
• in the logs, the requests is shown as cancelled

Suggestion

The "fire and forget" seems to be the only solution here.
We could have a separate service running the init without interruption.

No need at first for the whole progress bar shabang, but the init needs to get through always

Alternative

The ready flag could become a number of inserts already done so the next non-cancelled request could take over where the previous one left off.

Issue with alternative: How do we prevent exact concurrent pickup of same request (specially if it's an update concat)?

[elevatebart]

IDEA: In the meantime I would like to create an endpoint that will run this init asynchronously.

/api/content/:collection/init or /api/content/:collection/deploy

This would manually launch deployment of databases when things get borked and return immediately.
It could save some users bacon and be used to do the above suggestion later.

[elevatebart]

I found a helping tool here I think

https://nitro.build/guide/tasks

I feel that the initialization/update of the database should be a "Nitro task".

• It has to be done once and only once (cannot be run by multiple people)
• It should not be stopped before the end
• It could take longer than a typical efficient http request <- This ticket

I will investigate

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[elevatebart]

It is still absolutely a recurring problem in 3.4.0

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[elevatebart]

I will open a new issue if I find a way to fix it.
It does not seem to be a priority of yours.

Thank you anyway