Tiles at z17 not rendering properly

[talllguy]

I have observed that the tiles at z17 are not rendering with changes to the map. Their status date is Sat Jan 01 00:00:00 2000, which seems like an error. This does not affect z18-19 or 16-lower.

Steps to reproduce

Tested on Google Chrome Version 55.0.2883.87 m (64-bit)

1. Navigate to an area with some recent edits, e.g. here. Note that this is z16.
2. Disable cache for testing purposes
3. Force empty cache and reload (see Fig. A below). This will ensure that the latest non-cached tiles are loaded.
4. Zoom in a step to z17 and note the odd green notch in the park multipolygon. I fixed this over the weekend. Repeat step 3 to reload. When I tested this 31 Jan 2017 1511UTC, Fig. B is how z16 looked, and Fig. C is how z17 looked.
5. Try forcing a dirty status on one of the z17 tiles. Look in the dev tools Network tab for a PNG that should be updated, e.g. 49840.
6. add a /dirty to the end of the tile URL, i.e. http://c.tile.openstreetmap.org/17/37633/49840.png/dirty. You should see a message, "Tile submitted for rendering"
7. Wait a few minutes for good measure.
8. Repeat steps 2, 3, and 4 and note that there is no change.

Further analysis

I was showing a newly mapped woods trail to someone unfamiliar with OSM yesterday and noticed that the tiles were acting up on a computer browser that had never launched the OSM website.

I checked the tile status for the affected tiles, e.g. 49840, and noticed that the last rendered date is always Sat Jan 01 00:00:00 2000

Screenshots

Figure A (reload)

Figure B (z16)

Figure C (z17)

Figure D (tile 49840 status)

[talllguy]

I've also noticed that this same notch appears on other OSM based maps that typically update minutely, CC @aaronlidman

[tomhughes]

Operational issue, not a code bug.

[tomhughes]

The old date is not a problem by the way - if anything it is good because it shows the tile is dirty and due to be re-rendered when resources are available.

[tomhughes]

Note also that right now a new style is rolling out, so re-render requests are unlikely to be acted on immediately.

[tomhughes]

Just to confirm that timestamp is the one used to mark tiles as dirty when the data changes, so that tile is pending a re-render when resources are available.

[talllguy]

Tom, thanks for the prompt follow up and clarification on this issue. I was not aware that a new style was rolling out (other than occasional iterative updates over at openstreetmap-carto). Where can I find out more about the new style?

[tomhughes]

Usually release notes are posted to the lists but I don't believe that has happened this time. It's a matter for carto people though not me.

[talllguy]

I understand. Thanks for the information.

[HolgerJeromin]

@talllguy you can watch https://github.com/openstreetmap/chef/commits/master for updates. Often (always?) you will see an issue over there, too.

pnorman posted a mail on dev a few days ago.

[tomhughes]

Paul's email was actually about an upcoming change, not about this release.

[tomhughes]

Oh he did announce 3.1.0 as well.

[talllguy]

Thanks. We're talking about this message from @pnorman, which mentions osm2pgsql-dev/osm2pgsql#668 , correct?

[tomhughes]

No https://lists.openstreetmap.org/pipermail/dev/2017-January/029673.html is the one I meant.