Auto-starting batch process on enabling module can create problems

The problem is not the batch operation, per se, it's the fact that it launches itself upon enabling the module.

As a user, when I enable a module, I expect it to do some basic stuff like set up some database tables, expose some settings pages, and then basically immediately kick me back to the modules page so I can keep going on with my day. If there are time-consuming operations that need to occur, those things should happen either a) during cron, like search.module does, or b) upon button press somewhere in the settings page that clearly notes "this will take a long time," like rebuilding the node permissions table does.

This way, people would not click this button unless they were in a good place where they could tie up their computer for 4+ hours, unlike when you're quickly clicking through and enabling modules trying to get a site's functionality built, where it comes as a very nasty surprise. Worse, there appears to be no way to restart this process if it fails for whatever reason (like, for example, your Internet connection cuts out or your browser dies in the middle of processing). For this reason, I'm bumping to critical.

I killed the process only a little way in due to the fact that I had other things to do last night, but judging from the rate of the progress bar, this would've taken at least 4 hours to finish on my site. Therefore, I think this is not the kind of thing you ever want done in a browser window; browsers crash, windows get accidentally closed, etc. So I would advocate moving instead to the model that search.module uses, since building a search index is another operation that can take hours (or days) to complete.

Search module works by having a settings page at admin/settings/search with an indicator of indexing completion (99% of the site has been indexed. There are 7 items left to index.) and lets you specify how many items to index during a cron run (10, 20, 50, 100, 500, etc.). This way, if your cron jobs are not completing because of other things running in the background, you can try bumping the number down.

search_cron() is pretty straight-forward; just registers a small shutdown function to keep the totals up to date, and calls hook_update_index in every module, which includes node_update_index(), which does some fancy logic for weighting and then adds its results to the search index.

However, since that would probably be a big architectural change, and since everyone on this earth wants a 6.x release of this module as soon as possible, an interim fix would be to move the batch processing to the settings page with a progress indicator and a button to start/re-start it if it fails. This is the current approach that Calais module's bulk processing takes, although that maintainer is moving to a cron-based model as well since bulk-tagging legacy content is another potential 4+ hour operation.

No problem at all! Thanks for dealing with my snarky frustration last night. :D