LOD map render tiles gets corrupted/does not generate after a restart

template is bold sample data is italicized

Issue Description: I noticed a recurring issue lately on my map renders where if something interrupts the generation, like a server restart, the render resumes on the highest zom level (say, LOD0), it does not propagate properly to lower-res LOD’s (when you zoom out).

This results in a portion of black lines from where the rendering was interrupted, unless you zoom in all the way. This has happened on multiple maps, across the last 2 dynmap versions. While i would obviously like to know why is this happening or if there is a fix, my main gripe is the fact that if i do a dynmap radiusrender for the affected areas, it doesn’t even consider refreshing those non-LOD0 tiles, so essentially they can never be regenerated unless i purge the entire map and start over.

• Dynmap Version: Dynmap version: core=3.2-beta-2-483, plugin=3.2-beta-2-483
• Server Version: *Paper version git-Paper-642 (MC: 1.16.5) (Implementing API version 1.16.5-R0.1-SNAPSHOT)
• Pastebin of Configuration.txt: https://pastebin.com/Jds2H9rP
• Server Host (if applicable): self-hosted
• Pastebin of crashlogs or other relevant logs: n/a
• Other Relevant Data/Screenshots: This happens regardless of map version and while using no texture pack
• Steps to Replicate: (for simplicity) purge a world and force a fullrender. Stop the server normally midway through rendering, then start again and let it finish. Result: (continued below)

[x] I have looked at all other issues and this is indeed a duplicate of #2485! but i’m posting this since it was never an issue on our server before and wanted to know if this is

• something new in the last 2 dynmap versions,
• if it is related to my config and the use of cwebp or dwebp,
• OR related to using a particular paper version, since i saw it mentioned in a few threads.

[ x] I have been able to replicate this

[BrainStone]

There we go. I’d provide a build of that version, but the team seems to be against that sort of thing.
If you don’t know how to build it, DM me on Discord. I’m in the dynmap Discord with the same username and avatar.

[Pingger]

I may be getting this wrong but shouldn’t having initial-zoomout-validate: true prevent or at least address this issue in of itself? Talking about the “validating” part specifically here, because it clearly doesn’t… What does it validate for?

only the timestamps, but those are borked … dynmap saves the time the zoomout is saved to DB, instead of the timestamp of the “newest” sub-tile it used to render the zoomout, causing the race condition in a database, where the save operation is sometimes not visible for the read operation, when more than one thread for database-processing is used (the jdbc connector in dynmap ALWAYS uses more than 1 thread)

Consider Situation: we have tiles A.B,C,D and the zoomout Z. we change a block in D, D is rendered, which causes an update for Z to be queued. Z starts to be rendered, And gets the current state of A,B,C,D we change something in C. C is rendered. Does not queue Z to be updated, as it is still being rendered. Z is finished -> timestamp after C, zoomout-validate does not think Z need to be rerendered …