There is some cache mis-utilization introduced by #120. It looks like we'll still check the full range of entries for count and last addition, even though we only use a subset to render the tile. For tiles that represent just the last 24 hours of data, that will usually work but will be an inefficient query. If the client requests historical tiles, and if there have been new entries after that time range, then we will misreport that the data has changed. If the client is likely to issue requests for time periods that end "now", then we're also caching tiles that will likely never be requested again, and we're querying the cache for tiles that almost certainly don't exist.
I don't think we'll serve stale tiles, so this is a performance/storage risk and not a bad-data risk.
There is some cache mis-utilization introduced by #120. It looks like we'll still check the full range of entries for count and last addition, even though we only use a subset to render the tile. For tiles that represent just the last 24 hours of data, that will usually work but will be an inefficient query. If the client requests historical tiles, and if there have been new entries after that time range, then we will misreport that the data has changed. If the client is likely to issue requests for time periods that end "now", then we're also caching tiles that will likely never be requested again, and we're querying the cache for tiles that almost certainly don't exist.
I don't think we'll serve stale tiles, so this is a performance/storage risk and not a bad-data risk.