Mute ydb/tests/olap/s3_import/test_tpch_import.py.TestS3TpchImport.test_import_and_export in main

[ydbot]

Mute:
ydb/tests/olap/s3_import/test_tpch_import.py.TestS3TpchImport.test_import_and_export

Branch:
main

Build type:
relwithdebinfo

Owner: TEAM:@ydb-platform/cs

About this issue

• Auto-created by the mute workflow.
• Bot closes when all listed tests are unmuted or no longer exist.
• Close as Completed to trigger fast-unmute.
• mute_rules.md — full details.

Summary history:
test_tpch_import.py.TestS3TpchImport.test_import_and_export: Flaky(2026-08-15)->Passed(2026-08-16)->Flaky(2026-08-18) last 1 days, at 2026-08-15:2026-08-18: success_rate 66.7%, p-4, f-2, m-0, s-0, total-6

Test run history: link

More info in dashboard

[ydbot]

LLM instructions

Classify: TEST_ISSUE | YDB_ISSUE | TEST_INFRA_ISSUE
- YDB_ISSUE: product bug under ydb/core, ydb/library, etc.
- TEST_ISSUE: test logic, stale refs in helpers/workloads, missing waits. Fixture/harness PR
  that exposed a latent test bug → TEST_ISSUE; Responsible = fix path, not PR author.
- TEST_INFRA_ISSUE: shared harness/runner/CI broken for many unrelated tests. One directory /
  one test pattern → usually TEST_ISSUE, not TEST_INFRA_ISSUE.

Find root cause and introducing commit/PR; severity HIGH/MEDIUM/LOW; propose a fix.
In Root Cause list Suspect PR(s) most-likely-first (#12345 + why; tie to code/regression window).

Summary history (success_rate, p-*, f-*, total-*, dates): 50% often = runs before vs after a
merge, not a timing race. Compare failing tests with sibling tests (same fixture, still pass).

After fixture stop_driver(): "Driver was stopped" / "Topic client closed" → check stale driver
snapshot in workload/helpers before suggesting retries, sleeps, or graceful-shutdown revert.

VERIFY/SANITIZER — use status_description in exactly 3 lines:
  VERIFY failed (<ISO_UTC>): / ydb/.../file:line / assertion text (no stack frames, no +0x...)

Responsible (NOT issue-body Owner: — that is mute assignee only):
Pick team for the root-cause fix (first match):
  a) Fix path → .github/TESTOWNERS longest prefix (wins if PR exposed latent test bug)
  b) YDB_ISSUE → TESTOWNERS for broken ydb/... path
  c) Harness itself wrong → introducing PR author team
  d) Pure CI/Actions, no product commit → area/engineering
Map slug → area/... via .github/config/owner_area_mapping.json
Rules: root cause > Owner; commit from A exposing bug in B → B fixes; use area/queryprocessor not area/@ydb-platform/...

Reply exactly:
## Analysis
### Classification:
#### Error type: <TYPE>
#### Severity: <LEVEL>
#### Responsible: area/<team>
### Root Cause
<what broke>
Suspect PR(s), ordered by causality (most likely first):
1. #<pr> — <why>
### Suggested Fix
<fix or investigation>
### Summary
<2-4 sentences: failure, root cause, who fixes, next step>

Links to recent failed test runs

test	status	type	last_run	history	run	stderr	stdout	log	logsdir
test_tpch_import.py.TestS3TpchImport.test_import_and_export	failure	TIMEOUT	2026-08-18 02:34:27 UTC	link	link	n/a	n/a	link	link

[robot-vibe-db]

Analysis

Classification:

Error type: TEST_ISSUE

Severity: LOW

Responsible: area/cs

Root Cause

The test test_import_and_export performs a heavy workload (TPC-H scale=1: ~6M lineitem rows exported to S3 and imported back, plus two rounds of Digest::MurMurHash32(Pickle(TableRow())) hash validation over the full dataset) within a tight 900-second timeout. The failure type is TIMEOUT.

From the test log of the latest failed run, the typical execution profile is:

• Data generation (TPC-H init + import): ~1.5 min
• Export to S3 (INSERT INTO s3_table): ~30s
• Validation of s3_table (two complex hash queries): ~7 min
• Import back to YDB (CREATE TABLE AS SELECT): several minutes
• Validation of from_s3 (two complex hash queries): ~7 min

Total execution time is borderline at ~16 min, exceeding the 15-min (900s) timeout under CI resource pressure. The 66.7% success rate (4 pass / 2 fail out of 6 runs) and the pattern Flaky(Aug 15) → Passed(Aug 16) → Flaky(Aug 18) are consistent with a test that is right at the edge of its timeout limit, with CI environment variability (CPU/memory/disk contention in Regression-run_Large) tipping it over.

This test has a history of timeout-related muting; it was previously fixed in PR #32213 (Jan 2026).

Suspect PR(s), ordered by causality (most likely first):

1. NodePortionsCountLimit has been added #48268 — "NodePortionsCountLimit has been added" (merged Aug 14): Introduces optimizer runtime settings and modifies the columnshard planner construction path (granule.cpp, optimizer.h). While the default portions limit is high (1M), the changes to optimizer planner construction and new TOptimizerRuntimeSettings propagation could introduce marginal overhead in read/compaction paths, which is enough to push this borderline test over its timeout. Timeline matches: merged one day before first flakiness.
2. Cs flow control #48454 — "Cs flow control" (merged Aug 15): Large PR adding flow control to columnshard writes. The flow control itself is behind feature flag EnableCsFlowControl (default=false) so the main code path is not triggered, but this PR also modifies the overload manager (overload_manager_actor.cpp: +118/-2 lines), which could have subtle effects on write throughput during the import phase. Timeline matches the first flakiness date exactly.

No single PR is a clear smoking gun — the root cause is the test's borderline timeout relative to its workload, with recent columnshard infrastructure changes providing marginal additional pressure.

Suggested Fix

Option A (recommended): Increase the test timeout from 900 to 1200 seconds in ydb/tests/olap/s3_import/ya.make. This provides ~33% headroom and matches the test's actual execution profile.

Option B: Reduce the TPC-H scale factor from 1 to a smaller value (e.g., 0.1) if full scale-1 data volume is not strictly required for the export/import validation. This would reduce lineitem rows from ~6M to ~600K and significantly speed up all phases.

Option C: Simplify validation to avoid running the expensive MurMurHash32(Pickle(TableRow())) aggregation twice. A COUNT(*) comparison for the second validation pass (from_s3) would be sufficient to verify the import if the first pass already confirms data integrity.

Summary

The test_import_and_export test is failing with TIMEOUT because its 900-second limit is insufficient for TPC-H scale=1 export/import with dual hash-based validation. The 66.7% pass rate indicates a borderline timeout issue amplified by CI resource contention, possibly exacerbated by recent columnshard optimizer changes (#48268). The fix is to either increase the timeout to 1200s or reduce the test workload. This is a low-severity test infrastructure issue with no product correctness impact; the area/cs team owns both the test and the underlying columnshard code.

[robot-vibe-db]

Full analysis log

Analysis performed by claude, claude-opus-4-6.