Failure to retrieve a single zim file should not crash job

[Popolechien]

Following up on #563, it is a pity that the whole creation process, which is fairly lengthy, could crash because a single file is missing. Better have the installer skip this step and move on to the next - ideally sending a notification (on the cardshop) to the user to tell them a bit might be missing.

[rgaudin]

Disagrees. Either we have recurring download problems – which is not the case – that we can not overcome and then we offer the ability to choose what happens on download failures or we respect the order and fail the order in case an error happens.

it is a pity that the whole creation process, which is fairly lengthy, could crash because a single file is missing

Those single files are usually the very reason people are using the hotspot/cardshop… The ultimate user goal is to have an image with the content he chose inside, right?

Reminding here that although this failed run stopped after 1h38mn, it did fail early. Precisely to avoid failure at the end of this lengthy process, all remote files are downloaded first, before starting the building process. This run happened to have several large files ('wikipedia_en_all_maxi.en', 'gutenberg_en_all.en', 'wiktionary_en_all_maxi.en', 'wikipedia_en_medicine.en', 'wikisource_en_all_maxi.en')

@kelson42, your opinion on this?

[kelson42]

I have no strong opinion, it downloads from which mirror?

[rgaudin]

That seems only relevant to the other ticket, but:
It downloaded from mirror.download. @Popolechien selected a different variant and it passed so maybe it's a problem with a specific file

[kelson42]

After thinking twice about this ticket, I share @rgaudin opinion that the image creation shoukd die in such a scenario because in 90% of the cases it is not legit and we should not tolerate this.

But there is a few scenarios where this might be legit, see tickets like #571 or offspot/imager-service#242 or openzim/cms#7.