You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the spirit of tracking down bizarre corner-case issues, I discovered that a very small percentage of requests had failed to make their way into our analytics database. This only affected around 30 requests in the past month, so the percentages are quite small, but it's nonetheless concerning and something we should address.
The issue cropped up when the first request in a given month contained a query string parameter like '?something=2015-01-01. Due to how we index the query string parameters in our analytics database, this triggered Elasticsearch to index that as a special date type field. In general, all other requests would log fine, but where things broke was if someone then made a request for?something=2015-1-0(an invalid date) or?something=foo` (the same field, but with a string value). Since elasticsearch was treating that field as a date field (based on the first detected value), these subsequent requests would fail to log, since they contained invalid dates.
So while the number of affected requests that haven't been logged because of this issue have been very small, it's a very reproducible problem, and could become more of a problem if different APIs happened to use the same query string parameter for date vs non-dates.
The text was updated successfully, but these errors were encountered:
And additional tests added for this specific scenario, where the first seen requests contained date fields, but then subsequent requests passed in other values.
In the spirit of tracking down bizarre corner-case issues, I discovered that a very small percentage of requests had failed to make their way into our analytics database. This only affected around 30 requests in the past month, so the percentages are quite small, but it's nonetheless concerning and something we should address.
The issue cropped up when the first request in a given month contained a query string parameter like '?something=2015-01-01
. Due to how we index the query string parameters in our analytics database, this triggered Elasticsearch to index that as a special date type field. In general, all other requests would log fine, but where things broke was if someone then made a request for
?something=2015-1-0(an invalid date) or
?something=foo` (the same field, but with a string value). Since elasticsearch was treating that field as a date field (based on the first detected value), these subsequent requests would fail to log, since they contained invalid dates.So while the number of affected requests that haven't been logged because of this issue have been very small, it's a very reproducible problem, and could become more of a problem if different APIs happened to use the same query string parameter for date vs non-dates.
The text was updated successfully, but these errors were encountered: