fix(tests): make the image-preprocessing resize assertions actually assert

[Anai-Guo]

What

tests/workflows/integration_tests/execution/test_workflow_with_image_preprocessing.py has four shape checks written as assert (expr, "message"). That asserts a two-element tuple, which is always truthy — the checks have never verified anything.

assert (
    np_image.shape[0] == 1000,
    "Expected image to be resized to a width of 1000",
)
assert (np_image.shape[1] == 800, "Expected image to be resized to a height of 800")

Both test_resize_image_workflow_when_valid_input_provided and test_upsize_image_workflow_when_valid_input_provided are affected, so the only thing either test actually checks about the resize is that a resized_image key came back.

Why the parentheses were not the whole bug

Simply removing them turns both tests red — the indices are inverted as well.

RESIZE_IMAGE_WORKFLOW sets width: 1000, height: 800, and the block resizes with

# inference/core/workflows/core_steps/classical_cv/image_preprocessing/v1.py
resized_image = cv2.resize(np_image, (width, height), interpolation=cv2.INTER_AREA)

cv2.resize takes (width, height) and returns an array shaped (height, width, channels). So the output is (800, 1000, 3): shape[0] is 800 and shape[1] is 1000, while the assertions expect shape[0] == 1000 and shape[1] == 800. The messages name the right dimensions — "a width of 1000", "a height of 800" — they were just attached to the wrong axis.

Reproduced standalone against the same call the block makes:

>>> out = cv2.resize(np.zeros((1280,1920,3), np.uint8), (1000, 800), interpolation=cv2.INTER_AREA)
>>> out.shape
(800, 1000, 3)
shape[0] == 1000 -> False     # what the test asserts today
shape[1] == 800  -> False     # what the test asserts today
shape[0] == 800  -> True      # after this PR
shape[1] == 1000 -> True      # after this PR

Since both tests drive the same workflow, the target dimensions are the same regardless of which fixture image goes in.

The change

One test file; each assertion drops the tuple form and is matched to the dimension its message names.

Why lint did not catch it

check_code_quality already selects the rule — F63 covers F631 assertion is always true, perhaps remove parentheses? — but check_dirs := inference inference_sdk, so tests/ is never linted. Running the repo's own selection against the file reports exactly these four:

$ flake8 --count --select=E9,F63,F7,F82 tests/workflows/integration_tests/execution/test_workflow_with_image_preprocessing.py
...:78:5: F631 assertion is always true, perhaps remove parentheses?
...:82:5: F631 assertion is always true, perhaps remove parentheses?
...:114:5: F631 assertion is always true, perhaps remove parentheses?
...:118:5: F631 assertion is always true, perhaps remove parentheses?
4

and after this change it reports 0.

I left check_dirs alone rather than adding tests to it: the same selection currently reports 18 findings across tests/ (F632, F821, F824 in unrelated files), so widening it is a separate piece of work. Happy to open that as a follow-up if you want it.

black --check and isort --check-only pass on the file (it was black-clean before, and is after).

Scope of verification: the shape arithmetic above was reproduced directly; I did not run the workflow integration suite itself, which needs a model manager and fixture images.

🤖 Generated with Claude Code

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}