Add a non blocking batch runner

IMHO this sounds fantastic. For its use in the installer, but also in other cases, I think its important that it actually runs through, which is what may be hard to ensure. I guess you can already leave the page when a batch is running but now that it would be less evidently running, people may leave the page even more. That said, it would be fantastic if we would not block the user doing something just because we also need Drupal to do a lot of things in the background.

I guess you can already leave the page when a batch is running but now that it would be less evidently running, people may leave the page even more. That said, it would be fantastic if we would not block the user doing something just because we also need Drupal to do a lot of things in the background.

Yes this is going to be one of the harder pieces. We can probably cover a lot if we keep track in the user's session that they started a batch (probably the batch ID), check the session on every page request to see if we need to show the batch element, and then the element resumes where it left off if there's a batch still running. Then finishing a batch needs to clear $_SESSION['active_batches'] or similar.

Also the tricky part about this may be that the installer language import updates default config en masse so we nee to be careful what other config saves we allow at the same time as they may go over each other :)

A possible approach would be that when the batch is running, something like installing a new module via project browser would have to add a new item to the end of the batch instead of doing it immediately. Or a less complex implementation we could disable form submits while the batch is running (but not filling out form fields or clicking around the project browser UI for example).

I also think that, separately from this issue, we could add some parallelism to the language import batch via Fibers and guzzle async requests - like fire off 5 or 10 translation requests at a time per batch iteration. That could probably be done self-contained in its own issue, would make the current blocking batch a lot quicker, and mean much shorter windows for things to potentially go wrong or form submits to be prevented for this issue.

Yeah downloading the translation files could be very well parallelized, if d.o file server can handle the load :) Importing them I'm not sure can be parallelized since importing a .po file can have far reaching effects on dozens of config files at once. Then the importing next .po file is has effects on another dozen files, some overlap with the previous, etc.

Importing them I'm not sure can be parallelized since importing a .po file can have far reaching effects on dozens of config files at once. Then the importing next .po file is has effects on another dozen files, some overlap with the previous, etc.

Yeah importing we can't really do async with other imports, but we can do it once we've downloaded one file and are waiting for other ones to finish.

So instead of:

ABABABABABAB

It's more like:


ABBBBBB
AAA
A
A


Opened 📌 Parallelize config translation import Active .