The number of subpages is important because each page requires its own request. I'd say ideally we should restrict both.

@Samwilson So, this sounds like a plan for a more graceful fail. Which is good.

But just to be clear: does this mean we would never be able to download a book with a lot of chapters? (And pages—4500!) I.e., do we have any ideas for actually solving the problem?

That's a good question. The current workaround is for people to download wsexport and run it themselves locally. I've managed to produce an epub for the above work, for instance; it took quite a while and is 9300 pages.

The better fix for this would be for large items to be added to a job queue that's processed separately to the web tool. I'm not sure it's worth working on going straight to that architecture without first establishing how many files are 'too large' (although, maybe it's going to be hard to figure out what the size threshold is).

I think the first thing is to get some data about numbers of subpages in works on various Wikisources. Then we can see how many works will be unable to be exported; it might not be that many.

I think 500 subpages might be a good point to start at. Here is a summary of the numbers of works with numbers of subpages, and this lists page titles and their subpage counts (for both queries, I've experimented with a few different language Wikisources).

500 would currently exclude 47/443541 works on English Wikisource, 23/485826 on Russian, and 67/7562 on Bengali, for example.

We decided (in the estimation meeting) to leave this task as it is for now. If we see this being a thing users run into frequently, we should do something about it.

When I tested the link that previously had an error, I sometimes was able to download and I sometimes received a more helpful error message (see screenshot examples below). For this reason, I'm marking this work as resolved.