Retry locked mbtiles files

[Krizz]

Currently Martin stops in case of corrupt tile file or when tile file is in use (being created by tippecanoe).
It would be better to console log this as a warning, ignore the tile and continue running the tile server.

[CommanderStorm]

To make reproduction less time intensive:
What input files are you using and what is the error you get?

[CommanderStorm]

Update: I reproduced this via the example file from https://docs.mapbox.com/help/glossary/mbtiles/ (have submitted feedback about this, no need to report this to them)

@nyurik In case of an unrecoverable permanent error like this, failing obvious is better imo => what do you think?

[nyurik]

Thx for tracking it down! I agree that early failure is preferred, rather than having the service come up but unable to serve from one of its services. Note that this is different from the sporadic issues, e.g. network connection going down to a database or network issue with pmtiles - i.e. if we have a chance to recover later. I do think all sources should function during startup... Unless we want to introduce --allow-unavailable-sources ?

[CommanderStorm]

Let's not add this complexity for corrupted mbtiles files.

For locked ones though, I think retrying like proposed in this PR would be reasonable/preferale

• Retry connections to PostgreSQL before starting martin #1545

This is what is currently looks like:

[Krizz]

My use case is that I am generating a bunch of tiles dynamically while the app is already running. Ideally Martin would watch the directory and load the source when it is available and not corrupt (watch mode).

Validating every source and stopping Martin from starting seems a bit too strict to me. For example a web server/Plex/Winamp etc. will still start even if you have a corrupt file (source) in the directory that is being served.

I understand that early failure might be a design decision for Martin and my use case is out of scope - in that case I can just figure out a workaround or fork the code. Thank you!