Debugging flows

[guyisra]

We have rendered the world (partially successfully), yet we seem to sometimes missing tiles (from zoom 13 upwards)

Besides the seed all config, is there another config zoom limitation that could stop the processing (or enqueuing) of tiles? Using tileserver to server directly from the DB I see that the tiles do exist in the DB, so either they weren't enqueued (but since the high zoom levels are processed from the rawr tiles it's harder to debug) or something else happened.

1. Is there a config to limit zoom level processing?
2. What is the recommended flow to debug the processing of high zoom tiles?

[zerebubuth]

The seed command will make a job for every tile between the zoom levels configured, inclusive of the start and end zooms.

I've seen jobs can fail for a wide variety of reasons, so no obvious culprit comes to mind. Some of the ones I've seen, off the top of my head; out of memory, too many rate-limit (429) responses from S3, having the wrong bucket permissions, TTL expired, "Docker didn't start quickly enough", and - of course - tilequeue and vector-datasource software bugs.

Are you able to get the log files from the instance / container running the job? If not, and the failure is reproducible (e.g: putting a single tile coordinate in a file and feeding it to the "top tiles" seed config), then you could try running it locally and seeing what the error is?

Hope that helps!