[BUG] Ergast Backend fetch Failed

[Casper-Guo]

Describe the issue:

Found an error in the log of an automated data refresh workflow earlier today. Ergast sent a 503 HTTP response

Reproduce the code example:

session = fastf1.get_session(2024, 16, "R")

Error message:

WARNING session.py      Request for URL https://ergast.com/api/f1/2024/16/results.json failed; using cached response
Traceback (most recent call last):
  File "/home/robery/Armchair-Strategist/env/lib/python3.10/site-packages/requests_cache/session.py", line 291, in _resend
    response.raise_for_status()
  File "/home/robery/Armchair-Strategist/env/lib/python3.10/site-packages/requests/models.py", line 1024, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 503 Server Error: Backend fetch failed for url: https://ergast.com/api/f1/2024/16/results.json

WARNING session.py      Request for URL https://ergast.com/api/f1/2024/16/laps/1.json failed; using cached response
Traceback (most recent call last):
  File "/home/robery/Armchair-Strategist/env/lib/python3.10/site-packages/requests_cache/session.py", line 291, in _resend
    response.raise_for_status()
  File "/home/robery/Armchair-Strategist/env/lib/python3.10/site-packages/requests/models.py", line 1024, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 503 Server Error: Backend fetch failed for url: https://ergast.com/api/f1/2024/16/laps/1.json

[theOehrly]

The 503 is one of the multiple possible errors that may come up when Ergast is unreachable (depending on the current state of the server).

Generally, FastF1 is using the requests-cache package to make requests to any API with local caching. Here, the option stale_if_error=True is used so that requests-cache will return a stale response from the cache instead of an error when the API is unreachable. The rationale behind that is that all the data on the APIs changes rarely if ever. So an outdated locally cached response most likely is still completely valid.

Now, requests-cache still logs the request failure. For this, it uses the WARNING level (fairly high) which is by default shown when using FastF1. It also appends the traceback to this warning, which is why a traceback is shown despite the error being handled. For comparison, FastF1 shows warning text on the WARNING level and and displays the traceback separately on the DEBUG level. Therefore, users usually only see the warning itself and not the traceback, for warnings that are generated by FastF1 itself.

So overall, this is not really a problem but rather intended behaviour. I admit that the traceback in the output makes this fairly confusing. Right now, I think the only way to reasonably get rid of it is to make the logging configuration more fine grained so that logged messages from other modules are not shown. There are advantages and disadvantages to this, I guess.