Page MenuHomePhabricator

[Device Analytics] Invalid start or End date detail key is a list type and not string
Closed, InvalidPublicBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

  • Run the request in the code below
import requests


prod_url = 'https://wikimedia.org/api/rest_v1/metrics/unique-devices/en.wikipedia/all-sites/monthly/@20210501/@20210601'

header = {"accept": "application/json",
          "user-agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36"}

response = requests.get(prod_url, headers=header)

print(f"The response status code is: {response.status_code}")
print(response.json())

What happens?:
the detail key in the error reponse returns a string stype

local AQS 2.0 response:

invalid start date

{
   "detail":"start timestamp is invalid, must be a valid date in YYYYMMDD format",
   "method":"get",
   "status":400,
   "title":"Bad Request",
   "type":"about:blank",
   "uri":"/metrics/unique-devices/en.wikipedia/all-sites/monthly/@20210501/20210601"
}

invalid end date:

{
   "detail":"end timestamp is invalid, must be a valid date in YYYYMMDD format",
   "method":"get",
   "status":400,
   "title":"Bad Request",
   "type":"about:blank",
   "uri":"/metrics/unique-devices/en.wikipedia/all-sites/monthly/20210501/@20210601"
}

both:

{
   "detail":"start timestamp is invalid, must be a valid date in YYYYMMDD format",
   "method":"get",
   "status":400,
   "title":"Bad Request",
   "type":"about:blank",
   "uri":"/metrics/unique-devices/en.wikipedia/all-sites/monthly/@20210501/@20210601"
}

What should have happened instead?:
the detail key in the error reponse should return a list type

prod response :

invalid start date

{
   "type":"https://mediawiki.org/wiki/HyperSwitch/errors/invalid_request",
   "method":"get",
   "detail":[
      "start timestamp is invalid, must be a valid date in YYYYMMDD format"
   ],
   "uri":"/analytics.wikimedia.org/v1/unique-devices/en.wikipedia/all-sites/monthly/%4020210501/20210601"
}

invalid end date

{
   "type":"https://mediawiki.org/wiki/HyperSwitch/errors/invalid_request",
   "method":"get",
   "detail":[
      "end timestamp is invalid, must be a valid date in YYYYMMDD format"
   ],
   "uri":"/analytics.wikimedia.org/v1/unique-devices/en.wikipedia/all-sites/monthly/20210501/%4020210601"
}

Software version (skip for WMF-hosted wikis like Wikipedia):
N/A. All API based

both:

{
   "type":"https://mediawiki.org/wiki/HyperSwitch/errors/invalid_request",
   "method":"get",
   "detail":[
      "start timestamp is invalid, must be a valid date in YYYYMMDD format",
      "end timestamp is invalid, must be a valid date in YYYYMMDD format"
   ],
   "uri":"/analytics.wikimedia.org/v1/unique-devices/en.wikipedia/all-sites/monthly/%4020210501/%4020210601"
}

Event Timeline

This is not a bug. Per slack discussion, we are intentionally deviating from production behavior in this case. Here's part of that discussion:

we decided, for this particular case, to break compatibility with AQS 1.0 and have detail always be a string. The reason was that RFC 7807 says detail is a string. Therefore, we decided to consider the current AQS 1.0 behavior as a bug in that software that we should fix in AQS 2.0.
The AQS 1.0 developers were in general agreement with that plan.
This does create a small discrepancy between 1.0 and 2.0, but it is intentional, for a good reason, and unlikely to cause significant harm to callers. At least, that was our opinion last time we looked at this.

More relevant discussion on T302536: Problem details for HTTP APIs (rfc7807)