fix: handle FileNotFoundError when temporary file is missing in analysis workers

[bolinocroustibat]

Following the incident between Feb 26 and Mar 4, where a duplicate worker was running and could not find temporary files, analysis jobs were failing with a FileNotFoundError.
This exception was not caught by the outer except (ParseException, IOException) block, so it propagated without the useful attributes we have for ExceptionWithSentryDetails.

Why not just add FileNotFoundError to the outer except tuple?

The outer handler calls handle_parse_exception(e, ...), which accesses e.step and e.sentry_event_id — attributes defined by our custom ExceptionWithSentryDetails base class (from which ParseException and IOException both inherit). A native FileNotFoundError has none of these attributes, so passing it directly to handle_parse_exception would raise an AttributeError.

Instead, we wrap the read_or_download_file call in each analysis module with an inner try/except FileNotFoundError that re-raises as an IOException (with explicit message and context). This keeps the outer error handling pipeline intact and consistent with how all other errors are already handled in these functions.

[Pierlou]

Thanks for the fix! I am wondering whether we'd prefer to have the catch in read_or_download_file like:

if tmp_file:
   try:
      return open(file_path, "rb")
   except FileNotFoundError:
       ...

so that the logic is within the function. We should have the infos to pass on to Sentry in the check

[bolinocroustibat]

Thanks for the fix! I am wondering whether we'd prefer to have the catch in read_or_download_file like:

if tmp_file:
try:
return open(file_path, "rb")
except FileNotFoundError:
...
so that the logic is within the function. We should have the infos to pass on to Sentry in the check

@Pierlou That would indeed avoid the repetition, but that would make read_or_download_file helper depending on a custom IOException, meaning we would have to import and know the custom exceptions of the project here. While maybe we would prefer to keep read_or_download_file easy to be used everywhere as it's a simple helper?

I don't know what to think, both approaches make sense

[buzcu]

I believe instead of repeating the same safeguards in a 3 similarly close place it is better to only have it in read_or_download_file. It increases readability. Best regards