Not All Errors Are Equal

Two reports failed during last week’s monthly pull, and for a minute I treated them like the same problem.

They weren’t.

One was a typo in a report path. No amount of retrying was ever going to fix that. The other was a dropped connection while Alma was running a slower report. The path was fine. The request just needed another chance.

That distinction required a change in how the script handles failures.

try:
    return requests.get(url, params=params, timeout=timeout)
except (requests.exceptions.ConnectionError, requests.exceptions.Timeout):
    if attempt < retries:
        time.sleep(backoff * attempt)
        continue
    raise

Real errors from Alma fail immediately so I can fix them. Temporary connection issues get a few quiet retries before the script gives up.

That small change reminded me that the challenge has never really been getting data out of Alma. It has been learning to recognize when two things that look the same are actually different.

A snapshot is not the same as a running total. A report that returns one value is not the same as one that returns hundreds of records. A typo is not the same as a timeout.

None of these lessons required a major redesign. They each became a few lines of code, quietly encoding something I had to misunderstand before I could get it right.

The monthly pull now runs with very little attention from me, which is exactly what I wanted.

Maybe that’s true outside of software, too. Things that look alike are not always alike. Understanding the difference is usually where the real work begins.