[BUG] Unable to load session results

[jlp0422]

Describe the issue:

As of recent (last ~3 weeks), I'm unable to get accurate session.Results for any of the 2023 races. Was working great up through the Miami race, but now calling any race from 2023 gives no results for any of the race. Currently using version 2.3.0

Have noticed that now I see: core WARNING Failed to load data from Ergast API! (This is expected for recent sessions) in the logs, but not sure if this is expected and if so, why?

Reproduce the code example:

import fastf1

fastf1.Cache.enable_cache("cache")

session = fastf1.get_session(2023, "Miami", "Race")
session.load(telemetry=False, laps=False, weather=False)

core           INFO     Loading data for Miami Grand Prix - Race [v2.3.0]
api            INFO     Updating cache for driver_info...
api            INFO     Fetching driver list...
api            INFO     Cache updated!
core        WARNING     Failed to load data from Ergast API! (This is expected for recent sessions)
api            INFO     Updating cache for race_control_messages...
api            INFO     Fetching race control messages...
api            INFO     Cache updated!
core           INFO     Finished loading data for 20 drivers: ['11', '18', '22', '4', '21', '24', '44', '27', '23', '77', '1', '31', '16', '63', '10', '20', '55', '14', '81', '2']

# Running `session.results` then outputs (apologies if formatting is off, will provide screenshot):

    DriverNumber    BroadcastName   Abbreviation    TeamName    TeamColor   FirstName   LastName    FullName    Position    GridPosition    Q1  Q2  Q3  Time    Status  Points
11  11  S PEREZ PER Red Bull Racing 3671C6  Sergio  Perez   Sergio Perez    0.0 0.0                     0.0
18  18  L STROLL    STR Aston Martin    358C75  Lance   Stroll  Lance Stroll    0.0 0.0                     0.0
22  22  Y TSUNODA   TSU AlphaTauri  5E8FAA  Yuki    Tsunoda Yuki Tsunoda    0.0 0.0                     0.0
4   4   L NORRIS    NOR McLaren F58020  Lando   Norris  Lando Norris    0.0 0.0                     0.0
21  21  N DE VRIES  DEV AlphaTauri  5E8FAA  Nyck    De Vries    Nyck De Vries   0.0 0.0                     0.0
24  24  G ZHOU  ZHO Alfa Romeo  C92D4B  Guanyu  Zhou    Guanyu Zhou 0.0 0.0                     0.0
44  44  L HAMILTON  HAM Mercedes    6CD3BF  Lewis   Hamilton    Lewis Hamilton  0.0 0.0                     0.0
27  27  N HULKENBERG    HUL Haas F1 Team    B6BABD  Nico    Hulkenberg  Nico Hulkenberg 0.0 0.0                     0.0
23  23  A ALBON ALB Williams    37BEDD  Alexander   Albon   Alexander Albon 0.0 0.0                     0.0
77  77  V BOTTAS    BOT Alfa Romeo  C92D4B  Valtteri    Bottas  Valtteri Bottas 0.0 0.0                     0.0
1   1   M VERSTAPPEN    VER Red Bull Racing 3671C6  Max Verstappen  Max Verstappen  0.0 0.0                     0.0
31  31  E OCON  OCO Alpine  2293D1  Esteban Ocon    Esteban Ocon    0.0 0.0                     0.0
16  16  C LECLERC   LEC Ferrari F91536  Charles Leclerc Charles Leclerc 0.0 0.0                     0.0
63  63  G RUSSELL   RUS Mercedes    6CD3BF  George  Russell George Russell  0.0 0.0                     0.0
10  10  P GASLY GAS Alpine  2293D1  Pierre  Gasly   Pierre Gasly    0.0 0.0                     0.0
20  20  K MAGNUSSEN MAG Haas F1 Team    B6BABD  Kevin   Magnussen   Kevin Magnussen 0.0 0.0                     0.0
55  55  C SAINZ SAI Ferrari F91536  Carlos  Sainz   Carlos Sainz    0.0 0.0                     0.0
14  14  F ALONSO    ALO Aston Martin    358C75  Fernando    Alonso  Fernando Alonso 0.0 0.0                     0.0
81  81  O PIASTRI   PIA McLaren F58020  Oscar   Piastri Oscar Piastri   0.0 0.0                     0.0
2   2   L SARGEANT  SAR Williams    37BEDD  Logan   Sargeant    Logan Sargeant  0.0 0.0                     0.0

[jlp0422]

Screenshot as promised. I would expect to see the Position, GridPosition, etc populated with accurate data:

[jlp0422]

Seems like I'm running into this condition, just not sure why! https://github.com/theOehrly/Fast-F1/blob/287afe3b1a1cbcded80adb6056940f56c936d1c2/fastf1/core.py#LL1979C6-L1981C78

[pesaventofilippo]

I have the same problem. Not being able to load from Ergast is normal for recent events (for example, loading the current weekend or the race just after it completed), but lately is gives this error for all of the 2023 races and the session.results lacks most of the data in it.

edit: not just 2023 races. Even earlier years give the same problem.

edit 2: it seems like Ergast is the problem, not FastF1. Ergast's website currently throws an Internal Server Error when connecting to its database. Not sure though why FastF1 can't work without ergast, given that some time ago it could.

[theOehrly]

@jlp0422 Hi, thank you for reporting this. I hadn't noticed this yet because I don't actually have time to "use" FastF1 myself. Spare time goes into developing it 😅. And all test runs are heavily cached, masking the issue here.

The problem is in fact that the Ergast API is down, as correctly identified by @pesaventofilippo.

You are saying that this issue has been present for multiple weeks now? Does this happen only sometimes/most of the time/always? Just to clarify. I'm not maintaining Ergast, but I have set up some external monitoring now so that I'm able to get somewhat accurate statistics about uptime. Then I'll be able to better assess what needs to be done about this.

@pesaventofilippo

Not sure though why FastF1 can't work without ergast, given that some time ago it could.

Most features of FastF1 are designed to work without Ergast, but this specific data is only available from Ergast. There is no fallback for this data. The F1 API does not provide it. For Qualifying results, there currently exists a fallback that calculates the results (at least partially) from the timing data. Something like this could be implemented for race results as well. But there are a few major issues, and those are accuracy and completeness. The problem with accuracy is, that penalties that are applied after the race cannot be taken into account. Therefore, when calculating the finishing order, those results will fairly often be incorrect. And regarding completeness, some data just cannot be calculated, for example the reason why a specific car did not finish the race.

This is not a trivial problem to solve. The best thing would be if Ergast just starts working again properly. I'll keep a closer eye on this now and try to figure out what needs to be done and what can be done.

There's no workaround for this at the moment.

[pbkompasz]

@theOehrly It's live again.

[jlp0422]

@theOehrly Thanks for the reply!

You are saying that this issue has been present for multiple weeks now? Does this happen only sometimes/most of the time/always? Just to clarify.

I have a script that gets the latest race every Monday (to use the race results), and only since last week has it started giving me the Failed to load data from Ergast API! (This is expected for recent sessions.) I doubt it, but wondering if it could be related to the cancelled race at Imola a couple weeks ago? Any time previously (over the last ~10 months), I have not had any issues using the get_session method.

Most features of FastF1 are designed to work without Ergast, but this specific data is only available from Ergast. There is no fallback for this data. The F1 API does not provide it.

Just to clarify, the get_session method was always using the Ergast API under the hood?

There's no workaround for this at the moment.

😢

[theOehrly]

@pbkompasz

It's live again.

Hmm, not for me. Or it's down again.

@jlp0422

I doubt it, but wondering if it could be related to the cancelled race at Imola a couple weeks ago?

Highly unlikely, in my opinion. Ergast has increasingly had server issues over the last few months. They have been more intermittent though.

Just to clarify, the get_session method was always using the Ergast API under the hood?

Not exactly, get_session does only download schedule data. This is done either from my own backend or as a fallback from Ergast or from the F1 API (incomplete then), in that order.

Session.load will load data from multiple endpoints of the F1 API and from Ergast, merge data from various sources, use multiple sources to partially validate the data, detect and correct errors and augment additional information, and so on. In some places, when possible, fallbacks are implemented, but this is rare.

What you are seeing now is that one data source is unavailable, and therefore the data is incomplete while other parts of FastF1 are fully functional.

[pesaventofilippo]

@theOehrly by any chance do you know/have any contact for the people who maintain Ergast?

I have two servers with a 4Gbps connection each, I would be happy to provide a sort of mirror or fallback copy of the Ergast API at least until they manage to fix it.

I don't know how this could be done, as I don't know the origin of their problem, but I think getting at least some of the load off their servers could help.

[theOehrly]

@theOehrly by any chance do you know/have any contact for the people who maintain Ergast?

I have two servers with a 4Gbps connection each, I would be happy to provide a sort of mirror or fallback copy of the Ergast API at least until they manage to fix it.

I don't know how this could be done, as I don't know the origin of their problem, but I think getting at least some of the load off their servers could help.

I do know how to contact them, yes. And I will be reaching out to them within the next few days if this issue doesn't get resolved. I'll keep your offer in mind. I have thought about potentially creating a mirror/cache to reduce load before.

I just had a quick chat with someone else and there are some indications of ongoing server maintenance. Let's wait and see for a bit longer.

[pbulsink]

I've noticed at times that https:// connections to ergast fail, while http:// works. Would you consider a fallback to the http:// connection if the secure endpoint is unavailable?

[jmauczoio]

Hello! I am experiencing a similar problem: the code stops working after the last two lines: if I put a print before them it works, if I put it after it doesn't print the message.

import fastf1
fastf1.Cache.enable_cache('/Users/jacopo/Desktop/cache')
import matplotlib.pyplot as plt
import fastf1.plotting
fastf1.plotting.setup_mpl(misc_mpl_mods=False)

session = fastf1.get_session(...., ..., ...)
session.load()

I tried with different years, different sessions, but the problem still remains. The "funny" part is that I used the exact same code at 10:45 this morning and it was working and gave me the results I asked for.

I am not an expert, I just started, so I can't identify the ((errors)) messages properly. I hope this might help. These are some messages I get:

Traceback (most recent call last): File "/Users/jacopo/PycharmProjects/Formula 1/Analisi dati/N1_Velocità qualifiche.py", line 9, in session = fastf1.get_session(2023, 5, 'Q') ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/jacopo/PycharmProjects/Formula 1/Analisi dati/enviroment/lib/python3.11/site-packages/fastf1/events.py", line 275, in get_session event = get_event(year, gp, force_ergast=force_ergast, backend=backend) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ return super().send(request, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ r = adapter.send(request, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ resp = conn.urlopen( ^^^^^^^^^^^^^ sock = connection.create_connection( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @pesaventofilippo I meant the other messages, not the previous last line about terminating :)

[pesaventofilippo]

The "funny" part is that I used the exact same code at 10:45 this morning and it was working and gave me the results I asked for.

This is normal, as we said above, Ergast is having intermittent issues, so most likely when you ran the code this morning it worked because Ergast was up, and now it gives you an error because their website doesn't work.

Side note: the error you posted isn't very helpful, as all it says is that you terminated the program with ctrl-c, not the original source of the problem :)

[theOehrly]

I've noticed at times that https:// connections to ergast fail, while http:// works. Would you consider a fallback to the http:// connection if the secure endpoint is unavailable?

This might be an option, although it looks like things are getting resolved. This likely was just some major server maintenance. I don't think it's really worth to implement this fallback, once everything is back up and running.

[theOehrly]

Hello! I am experiencing a similar problem: the code stops working when I call

session = fastf1.get_session(...., ..., ...) session.load()

I tried with different years, different sessions, but the problem still remains. The "funny" part is that I used the exact same code at 10:45 this morning and it was working and gave me the results I asked for.

I am not an expert, I just started, so I can't identify the errors properly. I hope this might help. These are the errors I get:

[..]

@jmauczoio

1. Please spend some time formatting your error reports a bit more nicely. This stack trace is giving everybody headaches.

2. The actual code that you run matters. Please include a short self-contained example that reproduces the problem. This example should be code that can be executed by simply copy-pasting it without changing anything.

If you want me or someone else to look into problems that you encounter, you should please spend the time to give the necessary information in a readable format. Else you make it more difficult for everybody involved.

Now, I still spent the time to dig through this mess. This is actually unlikely to be caused by Ergast, judging by the called functions and FastF1 defaults. The actual URL was likely pointing to GitHub. So this is unrelated. If this continues to be a problem, please open a separate issue with more information.

(And I cleaned up your comment, to make this conversation more readable.)

[jmauczoio]

@theOehrly sorry for that, I modified the comment! Atm everything from server is working again, hopefully constantly :)

[SamBurky]

Hello,

I am also having a similar problem when attempting to load sessions. I've updated to the newest version of fastf1 and the issue still persists. Wondering if the issue is on my side or if Ergast is having ongoing issues. When running the code:

import fastf1
from fastf1 import plotting
from fastf1 import utils

# Select Drivers and Session
driver_1, driver_2 = 'VER', 'LEC'
year, grand_prix, session = 2022, 'Bahrain', 'Race'

# Load session
selected_session = fastf1.get_session(year, grand_prix, session)
selected_session.load()

I get the following returned:

core           INFO     Loading data for Bahrain Grand Prix - Race [v2.3.0]
api            INFO     Using cached data for driver_info
session     WARNING     Request for URL https://ergast.com/api/f1/2022/1/results.json failed; using cached response
Traceback (most recent call last):
  File "c:\Users\Samuel\Documents\Projects\formula1-telemetry\flask-server\venv\lib\site-packages\urllib3\connectionpool.py", line 703, in urlopen
    httplib_response = self._make_request(
  File "c:\Users\Samuel\Documents\Projects\formula1-telemetry\flask-server\venv\lib\site-packages\urllib3\connectionpool.py", line 386, in _make_request
    self._validate_conn(conn)
  File "c:\Users\Samuel\Documents\Projects\formula1-telemetry\flask-server\venv\lib\site-packages\urllib3\connectionpool.py", line 1042, in _validate_conn
    conn.connect()
  File "c:\Users\Samuel\Documents\Projects\formula1-telemetry\flask-server\venv\lib\site-packages\urllib3\connection.py", line 414, in connect
    self.sock = ssl_wrap_socket(
  File "c:\Users\Samuel\Documents\Projects\formula1-telemetry\flask-server\venv\lib\site-packages\urllib3\util\ssl_.py", line 449, in ssl_wrap_socket
    ssl_sock = _ssl_wrap_socket_impl(
  File "c:\Users\Samuel\Documents\Projects\formula1-telemetry\flask-server\venv\lib\site-packages\urllib3\util\ssl_.py", line 493, in _ssl_wrap_socket_impl
    return ssl_context.wrap_socket(sock, server_hostname=server_hostname)
  File "C:\Python39\lib\ssl.py", line 500, in wrap_socket
    return self.sslsocket_class._create(
  File "C:\Python39\lib\ssl.py", line 1040, in _create
    self.do_handshake()
  File "C:\Python39\lib\ssl.py", line 1309, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1123)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "c:\Users\Samuel\Documents\Projects\formula1-telemetry\flask-server\venv\lib\site-packages\requests\adapters.py", line 489, in send
    resp = conn.urlopen(
  File "c:\Users\Samuel\Documents\Projects\formula1-telemetry\flask-server\venv\lib\site-packages\urllib3\connectionpool.py", line 787, in urlopen
    retries = retries.increment(
  File "c:\Users\Samuel\Documents\Projects\formula1-telemetry\flask-server\venv\lib\site-packages\urllib3\util\retry.py", line 592, in increment
    raise MaxRetryError(_pool, url, error or ResponseError(cause))
urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='ergast.com', port=443): Max retries exceeded with url: /api/f1/2022/1/results.json (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1123)')))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "c:\Users\Samuel\Documents\Projects\formula1-telemetry\flask-server\venv\lib\site-packages\requests_cache\session.py", line 230, in _resend_and_ignore
    response = self._send_and_cache(request, actions, cached_response, **kwargs)
  File "c:\Users\Samuel\Documents\Projects\formula1-telemetry\flask-server\venv\lib\site-packages\requests_cache\session.py", line 189, in _send_and_cache
    response = super().send(request, **kwargs)
  File "c:\Users\Samuel\Documents\Projects\formula1-telemetry\flask-server\venv\lib\site-packages\requests\sessions.py", line 701, in send
    r = adapter.send(request, **kwargs)
  File "c:\Users\Samuel\Documents\Projects\formula1-telemetry\flask-server\venv\lib\site-packages\requests\adapters.py", line 563, in send
    raise SSLError(e, request=request)
requests.exceptions.SSLError: HTTPSConnectionPool(host='ergast.com', port=443): Max retries exceeded with url: /api/f1/2022/1/results.json (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1123)')))
api            INFO     Using cached data for timing_data
api            INFO     Using cached data for timing_app_data
core           INFO     Processing timing data...
api            INFO     Using cached data for session_status_data
api            INFO     Using cached data for track_status_data
api            INFO     Using cached data for car_data
api            INFO     Using cached data for position_data
api            INFO     Using cached data for weather_data
api            INFO     Using cached data for race_control_messages
core           INFO     Finished loading data for 20 drivers: ['16', '55', '44', '63', '20', '77', '31', '22', '14', '24', '47', '18', '23', '3', '4', '6', '27', '11', '1', '10']

Also, thank you for building and maintaining fastf1, its awesome.

[theOehrly]

@jmauczoio

Atm everything from server is working again, hopefully constantly :)

Ok, good. If the error comes back, as said, please open a separate issue. This really seems to be different.

[theOehrly]

@SamBurky I can reproduce this problem right now. It's a bit weird, because I can request data from this endpoint in my browser and there are no SSL certificate errors. I'm tempted to say, it's Ergast's fault again, but I'll investigate it a bit more.

Edit: By the looks of it, there are some problems in the certificate chain of Ergast's new SSL cert. Therefore, the certificate is not trusted (by some clients at least). This has already been reported so I hope it will be fixed soon.

[theOehrly]

The certificate issue is resolved, by the looks of it. A quick check just now seemed to show that everything works correctly again.

[jlp0422]

Started working again for me Saturday night 🎉

[christianfiles]

Hi @theOehrly I am having a very similar issue as @SamBurky as mentioned above...

I managed to get everything working a few days ago and have since had no luck when running the following commands:

# Import libraries
import fastf1 as ff1

# Enable verbose logging messages printed to console
ff1.logger.LoggingManager.debug=True

# Loading session
session = ff1.get_session(2023, 'Silverstone', 'R')
session.load()

Output:

core           INFO     Loading data for British Grand Prix - Race [v3.0.6]
_api           INFO     Fetching driver list...
core        WARNING     Failed to load extended driver information!
_api           INFO     Fetching session status data...
Traceback (most recent call last):
  File "C:\Users\christf\AppData\Local\Programs\Python\Python310\lib\site-packages\urllib3\connectionpool.py", line 467, in 
_make_request
    self._validate_conn(conn)
  File "C:\Users\christf\AppData\Local\Programs\Python\Python310\lib\site-packages\urllib3\connectionpool.py", line 1092, in _validate_conn
    conn.connect()
  File "C:\Users\christf\AppData\Local\Programs\Python\Python310\lib\site-packages\urllib3\connection.py", line 635, in connect
    sock_and_verified = _ssl_wrap_socket_and_match_hostname(
  File "C:\Users\christf\AppData\Local\Programs\Python\Python310\lib\site-packages\urllib3\connection.py", line 776, in _ssl_wrap_socket_and_match_hostname
    ssl_sock = ssl_wrap_socket(
  File "C:\Users\christf\AppData\Local\Programs\Python\Python310\lib\site-packages\urllib3\util\ssl_.py", line 466, in ssl_wrap_socket
    ssl_sock = _ssl_wrap_socket_impl(sock, context, tls_in_tls, server_hostname)
  File "C:\Users\christf\AppData\Local\Programs\Python\Python310\lib\site-packages\urllib3\util\ssl_.py", line 510, in _ssl_wrap_socket_impl
    return ssl_context.wrap_socket(sock, server_hostname=server_hostname)
  File "C:\Users\christf\AppData\Local\Programs\Python\Python310\lib\ssl.py", line 513, in wrap_socket
    return self.sslsocket_class._create(
  File "C:\Users\christf\AppData\Local\Programs\Python\Python310\lib\ssl.py", line 1071, in _create
    self.do_handshake()
  File "C:\Users\christf\AppData\Local\Programs\Python\Python310\lib\ssl.py", line 1342, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1007)

I have tried updating ssl certificates and also reinstalling ca-certificates etc, but with no such luck.

I too am wondering if this issue is on my side or if Ergast is still having ongoing issues?

Thanks!

[theOehrly]

@christianfiles there are currently no known issues with Ergast or the F1 Livetiming API.

From this traceback, I can't tell exactly which request failed, probably multiple ones. But at first glance this seems like a more general problem, not specific to Ergast.

Are you using FastF1 in a corporate environment or on some other type of protected network?

Also, did you write the comments in that script? Because the comment about what LoggingManager.debug = true does, is not really correct.

[christianfiles]

@theOehrly Thanks for the quick response.

I am trying this out on a protected network at the moment. So, this could be my issue.

It isn't a script, it is just general notes that I had written down myself. Noted about the comment, thanks. Was purely using it for debugging purposes.

[theOehrly]

@christianfiles you're issue is potentially this: https://github.com/theOehrly/Fast-F1/discussions/405#discussioncomment-6253253

Would be cool if you can give a quick feedback in case that fixes the problem.

[christianfiles]

@theOehrly Looks like it was the same issue. I added some certificates and it now runs without any SSL errors. Thanks!