Yicong-Huang opened a new pull request, #4677: URL: https://github.com/apache/texera/pull/4677
### What changes were proposed in this PR? **Draft / diagnostic** — wrap \`DataProcessingSpec.withFixture\` with a nano-timer and dump a sorted per-test elapsed-time table in \`afterAll\`. \`DataProcessingSpec\` is the dominant contributor to scala test wall time on a typical main-push run (its 16 e2e workflow tests run for the full ~6 minute test phase, with each test bounded by a 1-minute \`Await\`). Without per-test numbers there is no way to decide which workflows to consolidate or delete. This change is intended to land long enough to gather one CI run's worth of timings; once the slow tests are identified (#4670 follow-up), this instrumentation is expected to be removed or rewritten as a stricter timeout per test. \`\`\` [info] DataProcessingSpec per-test timings (sorted desc, total NNNNms across 16 tests): [info] XXXXXms Engine should execute csv->keyword->averageAndGroupBy workflow normally [info] ... \`\`\` ### Any related issues, documentation, discussions? Diagnostic for the scala build wall-time discussion. Findings will feed a follow-up that either consolidates redundant e2e workflows or fixes the underlying retry flake the suite documents. ### How was this PR tested? No new tests. The instrumentation runs as part of the existing \`DataProcessingSpec\` execution under the python/scala/agent-service \`Build\` matrix. After this PR's CI run, the scala job log under \`build / scala (ubuntu-22.04, 11)\` will contain the sorted timing table. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Opus 4.7, 1M context) -- 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]
