UTF8 grid contains unexpected field names

[strk]

We've hit some cases in which the returned UTF8 grid from a GET grid operation contain data which do not belong to the requested table. It looks like some cache is being hit, but it's all internal to the tiler.

Very hard to reproduce.

[strk]

Issue can be seen here:
http://erepublik.cartodb.com/tiles/regions/7/84/39.grid.json?interactivity=cartodb_id
the returned grid has more than "cartodb_id".
Fetching tile 7/84/30 instead gives only "cartodb_id" as requested.

One difference seems to be that 7/84/39 (the bogus one) has no features shown in the grid (or that's another bug, given there is a feature in the data part).

[strk]

I could reproduce locally, fetching tile 13/5019/3945 from the shared world borders dataset. The tile is fully within a feature, which is styled with a polygon symbolizer and a line symbolizer.

It's interesting that specifying an unexistent field as interactivity triggers an error from the mapnik postgis plugin (ERROR: column "lalala" does not exist) but specifying an existing field (for example iso2) simply keeps only returning cartodb_id in my case.

[strk]

Alright so steps to reproduce:

1. Find a tile which is fully within a rendered feature (13/5019/3945 with tm dataset is a good one)
2. Fetch a grid, specifying a custom interactivity parameter (for example interactivity=iso3)
3. Verify that you get the requested field in the grid. If it fails, restart the tiler and it should work
4. Now request the same grid with a different interactivity value (for example interactivity=iso2)

Expected behavior: you get the new interactivity field.
Obtained behavior: you still get the old interactivity field.

Observations:

1. Restarting the tiler and reloading the final url does correctly show the new field
2. The node-mapnik routine used to render a grid is invoked and correctly sees the new interactivity field name
3. Changing the interactivity parameter value does force the creation of a new renderer
4. Also changing the cache_buster parameter forces a creation of a new renderer but doesn't fix the problem

I start suspecting the bug is some level up from node-mapnik (due to point 2 above).

/cc @springmeyer

[strk]

Commenting out the cached return in tilelive-mapnik render.js:96 (in getImage) fixes this case.
This is tilelive-mapnik 0.3.3-dev (cartodb fork)

[strk]

So this specific issue has been fixed with a quick workaround in our fork of tilelive-mapnik, but still needs an automated test and a proper fix.

[strk]

Automated test added in windshaft.

[strk]

I guess it's been tested enough (9 months !)