Page MenuHomePhabricator

Toolviews /daily API call returns 404
Closed, ResolvedPublicBUG REPORT

Description

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

What happens?:
A 404 is returned (The requested URL was not found on the server. If you entered the URL manually please check your spelling and try again.)

What should have happened instead?:
Daily results for all tools between 2020-03-01 and 2020-03-31 should have been returned

Software version (skip for WMF-hosted wikis like Wikipedia):

Other information (browser name/version, screenshots, etc.):

  • /day/{date} works
  • /tool/{tool}/day/{date} works
  • /tool/{tool}/daily/{start}/{end} does not work

Event Timeline

tools.toolviews@shell-1680652650:~/www/python/src$ ../venv/bin/python3
Python 3.9.2 (default, Feb 28 2021, 17:03:44)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import app
>>> app.app.url_map
Map([<Rule '/static/<filename>' (GET, OPTIONS, HEAD) -> static>,
 <Rule '/flasgger_static/<filename>' (GET, OPTIONS, HEAD) -> flasgger.static>,
 <Rule '/api/' (GET, OPTIONS, HEAD) -> flasgger.apidocs>,
 <Rule '/apidocs/index.html' (GET, OPTIONS, HEAD) -> flasgger.<lambda>>,
 <Rule '/api/v1/apispec.json' (GET, OPTIONS, HEAD) -> flasgger.apispec_1>,
 <Rule '/' (GET, OPTIONS, HEAD) -> index>,
 <Rule '/api/v1/tool/<tool>/day/<day>' (GET, OPTIONS, HEAD) -> get_hits_for_date>,
 <Rule '/api/v1/day/<day>' (GET, OPTIONS, HEAD) -> get_hits_for_date>,
 <Rule '/api/v1/unique/tool/<tool>/day/<day>' (GET, OPTIONS, HEAD) -> get_unique_hits_for_date>,
 <Rule '/api/v1/unique/day/<day>' (GET, OPTIONS, HEAD) -> get_unique_hits_for_date>,
 <Rule '/api/v1/tool/<tool>/daily/<start>/<end>' (GET, OPTIONS, HEAD) -> get_hits_for_daterange>,
 <Rule '/api/v1/daily/<start>/<end>' (GET, OPTIONS, HEAD) -> get_hits_for_daterange>,
 <Rule '/api/v1/unique/tool/<tool>/daily/<start>/<end>' (GET, OPTIONS, HEAD) -> get_unique_hits_for_daterange>,
 <Rule '/api/v1/unique/daily/<start>/<end>' (GET, OPTIONS, HEAD) -> get_unique_hits_for_daterange>,
 <Rule '/api/v1/tools' (GET, OPTIONS, HEAD) -> get_tools>])

The app does have an <Rule '/api/v1/daily/<start>/<end>' (GET, OPTIONS, HEAD) -> get_hits_for_daterange> object in it's internal routes, but the app is also emitting the 404 response code itself:

$ grep '/api/v1/daily/' uwsgi.log
[pid: 14|app: 0|req: 26/87] 192.168.247.79 () {54 vars in 975 bytes} [Mon Mar 27 18:47:24 2023] GET /api/v1/daily/2020-03-01/2020-03-31 => generated 207 bytes in 3 msecs (HTTP/1.1 404) 3 headers in 119 bytes (1 switches on core 0)
[pid: 14|app: 0|req: 29/91] 192.168.247.79 () {54 vars in 981 bytes} [Mon Mar 27 18:49:31 2023] GET /api/v1/daily/2020-03-01/2020-03-31 => generated 207 bytes in 2 msecs (HTTP/1.1 404) 3 headers in 119 bytes (1 switches on core 0)
[pid: 14|app: 0|req: 30/92] 192.168.209.151 () {56 vars in 1059 bytes} [Mon Mar 27 18:50:54 2023] GET /api/v1/daily/2020-03-01/2020-03-31 => generated 207 bytes in 3 msecs (HTTP/1.1 404) 3 headers in 119 bytes (1 switches on core 0)
[pid: 14|app: 0|req: 32/96] 192.168.190.209 () {64 vars in 1306 bytes} [Mon Mar 27 19:22:06 2023] GET /api/v1/daily/2020-03-01/2020-03-31 => generated 207 bytes in 7 msecs (HTTP/1.1 404) 3 headers in 119 bytes (1 switches on core 0)
[pid: 13|app: 0|req: 28/105] 192.168.247.79 () {56 vars in 1064 bytes} [Mon Mar 27 19:54:12 2023] GET /api/v1/daily/2020-03-01/2020-03-31 => generated 207 bytes in 4 msecs (HTTP/1.1 404) 3 headers in 119 bytes (1 switches on core 0)
[pid: 11|app: 0|req: 8/43] 192.168.247.67 () {60 vars in 1101 bytes} [Sat Apr  1 09:21:37 2023] GET /api/v1/daily/2020-03-01/2020-03-31 => generated 207 bytes in 10 msecs (HTTP/1.1 404) 3 headers in 119 bytes (1 switches on core 0)
[pid: 14|app: 0|req: 21/58] 192.168.190.197 () {56 vars in 1029 bytes} [Tue Apr  4 23:46:11 2023] GET /api/v1/daily/2023-03-01/2023-03-31 => generated 207 bytes in 5 msecs (HTTP/1.1 404) 3 headers in 119 bytes (1 switches on core 0)
[pid: 14|app: 0|req: 7/16] 192.168.209.132 () {58 vars in 1116 bytes} [Wed Apr  5 00:00:49 2023] GET /api/v1/daily/2020-03-01/2020-03-31 => generated 207 bytes in 4 msecs (HTTP/1.1 404) 3 headers in 119 bytes (1 switches on core 0)

This needs more invasive debugging apparently.

bd808 triaged this task as Medium priority.Apr 5 2023, 5:17 PM
bd808 edited projects, added Tool-toolviews; removed Tools.
bd808 moved this task from Backlog to Ready on the Tool-toolviews board.

I apparently forgot to give a update here after my first round of deep dive. I have been able to convince myself that the routes are registered with flask's core router and that when the 404 is emitted the route known to the system matches a registered route. This last part was done by live hacking the source running at https://toolviewstest.toolforge.org to add a custom 404 handler that dumps the path as part of the response payload.

The correlated pattern of routes that fail with a 404 seems to be having the consecutive /<start>/<end> final path components to parse and pass on to the view method. Putting more labels in the path (e.g. /start/<start>/end/<end>) did not change the (mis)behavior.

bd808 claimed this task.
bd808 moved this task from Ready to Doing on the Tool-toolviews board.

This seems to be fixed, but I must admit I am not exactly sure what change I made between R2333:6c764990d6bd: api: Update example dates to current year and R2333:7033053b03d3: README: update content fixed it.