Skip to content

fix(tests): isolate state in test_write_optional_list#3334

Open
paultmathew wants to merge 1 commit intoapache:mainfrom
paultmathew:fix/test-write-optional-list-not-cleaning-state
Open

fix(tests): isolate state in test_write_optional_list#3334
paultmathew wants to merge 1 commit intoapache:mainfrom
paultmathew:fix/test-write-optional-list-not-cleaning-state

Conversation

@paultmathew
Copy link
Copy Markdown

Rationale for this change

test_write_optional_list uses create_table_if_not_exists and then asserts exact row counts (2 after the first append, 4 after the second). The table is reused across runs, so a second invocation against the same docker-compose stack accumulates rows — counts become 6, 10, 14, … and the asserts fail.

CI hides this because it spins up a fresh docker-compose-integration stack for every job. Locally it bites anyone who runs make test-integration-exec twice without make test-integration-cleanup in between.

Fix: drop the table at the start so the test always starts from a clean slate, matching the drop-then-create pattern used by _create_table() for every other write test in this module.

Are these changes tested?

Yes — verified locally that the test now passes when run twice back-to-back without resetting the docker stack:

docker compose -f dev/docker-compose-integration.yml up -d --wait
uv run python dev/provision.py
uv run python -m pytest tests/integration/test_writes/test_writes.py::test_write_optional_list -m integration  # PASS
uv run python -m pytest tests/integration/test_writes/test_writes.py::test_write_optional_list -m integration  # PASS (was previously: 8 == 2)

Full tests/integration/test_writes/test_writes.py suite: 122 passed, 1 skipped.

Are there any user-facing changes?

No.


Noticed while preparing the PR for #2152 (RecordBatchReader streaming append).

`test_write_optional_list` uses `create_table_if_not_exists` and then asserts
exact row counts after two `tbl.append()` calls. On any subsequent run the
table is reused, so the asserted counts (2, then 4) become 6, 10, ... and the
test fails. The failure only surfaces when the integration suite is replayed
without a fresh docker-compose stack, which masks the bug in CI but makes it a
papercut for local development.

Drop the table at the start to guarantee a clean slate, matching the pattern
used by `_create_table()` for every other write test in this module.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant