DEV Community

B W
B W

Posted on

The Counter That Counted a Call the Preflight Never Reached

#devchallenge #bugsmash #python #testing

Summer Bug Smash: Clear the Lineup 🐛🛹

This is a submission for DEV's Summer Bug Smash: Clear the Lineup, powered by Sentry.

Project Overview

I was working on a small Python component that performs a preflight check and
then, if the check succeeds, invokes one synchronous operation callback. A
counter records whether that callback invocation returned normally.

The counter is used for diagnostics, so it must follow the control flow rather
than the expected happy path.

Bug Fix or Performance Improvement

When a handled failure occurred, the old implementation still returned one:

return 1
Enter fullscreen mode Exit fullscreen mode

That value was hard-coded because the successful path was expected to invoke
exactly one operation. If the preflight check failed, however, the operation
was never entered and the function still returned one.

An offline reproduction produced:

operation_entries=0
old_count=1
Enter fullscreen mode Exit fullscreen mode

The failure was handled, but the counter contradicted the actual control flow.

Code

Reduced to the relevant lines, the old behavior was:

# Simplified pre-fix behavior
def buggy_completed_calls(*, preflight, operation):
    try:
        preflight()
        operation()
    except Exception:
        pass
    return 1
Enter fullscreen mode Exit fullscreen mode

Here is the complete fixed function from the standalone reproducer:

from collections.abc import Callable

Callback = Callable[[], None]

def completed_calls(*, preflight: Callback, operation: Callback) -> int:
    """Return one only when the cooperative operation returned normally."""

    try:
        preflight()
        operation()
    except Exception:
        return 0
    return 1
Enter fullscreen mode Exit fullscreen mode

The essential regression assertion is shown below. Both callbacks are local,
so the test performs no network request:

# Abbreviated test excerpt
def test_preflight_failure_does_not_count_an_unentered_operation():
    operation_entries = 0

    def refuse_preflight():
        raise RuntimeError("controlled preflight refusal")

    def operation():
        nonlocal operation_entries
        operation_entries += 1

    result = completed_calls(
        preflight=refuse_preflight,
        operation=operation,
    )

    assert operation_entries == 0
    assert result == 0
Enter fullscreen mode Exit fullscreen mode

My Improvements

The design change is simple: a handled failure returns zero directly, while the
only path to one comes after the operation callback invocation returns normally.
Expected control flow no longer substitutes for observed control flow.

I verified the change with:

  • an exact before/after replay of the preflight failure;
  • tests under normal Python execution and python -O;
  • in-memory compilation checks;
  • no network or external service access.

The exact invariant fixed here is:

PREFLIGHT_RAISES_EXCEPTION_BEFORE_OPERATION_CALL => completed_calls == 0
Enter fullscreen mode Exit fullscreen mode

Here, EXCEPTION means Python's Exception, not BaseException. There is
another important boundary I do not want to hide: the counter measures normal
callback-invocation returns, not deferred work or remote side effects. If a
called operation causes an external effect and then raises while waiting for a
result, this integer alone cannot describe what happened remotely.

The declared profile is ordinary cooperative synchronous application code in
one process. This helper is not a sandbox for hostile callbacks.

Within its stated scope, the bug is closed: a preflight failure can no longer
produce a false-positive completed-call count.

Top comments (0)