sadpandajoe opened a new pull request, #44399: URL: https://github.com/apache/superset/pull/44399
### SUMMARY The nightly `testcontainers (db2, 25)` leg fails intermittently with `TimeoutError: Wait time (120.0s) exceeded for _connect` ([run 35185304121](https://github.com/apache/superset/actions/runs/35185304121/job/105086001403)). **Root cause.** `Db2Container._connect` (testcontainers 4.15.0, `community/db2/__init__.py:54-56`) calls `wait_for_logs(self, predicate="Setup has completed")` with no explicit timeout, so it inherits the library's global default — `max_tries` (120) × `sleep_time` (1s) = **120s** (`core/config.py:103-104,160-161`). That value is bound as a *default argument* when `core/waiting_utils` is imported, and `Db2Container` exposes no constructor argument to widen it (`**kwargs` is forwarded to `docker_client.create()`, not to the waiter). A full Db2 instance bring-up varies widely. Across the retained nightly runs the pytest session for this module measured **88s to 153s** end to end, so a hard 120s cap on the boot wait alone has near-zero margin. In the failing run the container was still `running` and had just logged `(*) Creating database testdb ...` when the timer expired — a slow boot, not a broken container or a stale predicate. The 25-minute *job* budget is unrelated and was nowhere near binding: that job used 4m02s. **Fix.** Attach an explicit wait strategy before starting the container, matching the idiom already used by `test_databend.py`, `test_monetdb.py`, `test_oceanbase.py`, `test_risingwave.py` and `test_yugabytedb.py`. `DbContainer.start()` delegates to `DockerContainer.start()`, which honors `_wait_strategy` (`core/container.py:280-286`), so this runs to completion *before* `_connect` is called. `LogMessageWaitStrategy` searches the full accumulated `container.get_logs()` with the same pattern, so `_connect` then matches on its first poll and its own 120s window is permanently off the critical path — no library internals are monkeypatched and no private method is overridden. **Behavior change worth noting:** `LogMessageWaitStrategy` also raises `RuntimeError` if the container exits before the message appears (`core/wait_strategies.py:138-150`). This is an improvement — a crashed Db2 now fails fast instead of burning the full timeout — but it is a change from the previous behavior, which would have waited out the whole window regardless. ### BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF N/A — not a UI change. ### TESTING INSTRUCTIONS This cannot be verified on Apple Silicon: `icr.io/db2_community/db2` publishes no arm64 build. On an x86_64 host with Docker: ```bash uv pip install -e .[db2] pytest -v -m testcontainers tests/testcontainers/db_engine_specs/test_db2.py ``` Otherwise, trigger the Testcontainers workflow via `workflow_dispatch` on this branch and confirm the `testcontainers (db2, 25)` leg is green. Because the failure is an intermittent margin problem (1 failure in the 8 retained nightly runs), a single green run confirms no regression but not the absence of the original defect; the nightly cron is the real signal. No hermetic unit test is possible here — the defect is wall-clock margin against a real container boot, which needs Docker and a multi-GB image. The rationale for the 900s value is recorded in a comment in the fixture in place of the test that cannot be written. ### ADDITIONAL INFORMATION - [x] Has associated issue: Fixes #44372 - [ ] Required feature flags: - [ ] Changes UI - [ ] Includes DB Migration (follow approval process in [SIP-59](https://github.com/apache/superset/issues/13351)) - [ ] Migration is atomic, supports rollback & is backwards-compatible - [ ] Confirm DB migration upgrade and downgrade tested - [ ] Runtime estimates and downtime expectations provided - [ ] Introduces new feature or API - [ ] Removes existing feature or API -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
