test(oracledb): bound connect and query timeouts in the ESM integration fixture#9105
Conversation
…on fixture The ESM integration fixture connected with no client-side timeout, so a stalled Oracle round-trip hung the subprocess until the 20s mocha per-test timeout fired with no diagnosable error. CI hit this intermittently: five of six sibling ESM subprocesses connected and ran the query in ~0.5s while one wedged for the full window. connect_timeout bounds the connect phase and callTimeout bounds each query round-trip, so a stalled session now throws (NJS-123 / a connect error) well inside the budget and the test fails fast and attributable instead of as a generic timeout. Refs: oracle/node-oracledb#1592
Overall package sizeSelf size: 6.39 MB Dependency sizes| name | version | self size | total size | |------|---------|-----------|------------| | import-in-the-middle | 3.2.0 | 104.26 kB | 843.44 kB | | opentracing | 0.14.7 | 194.81 kB | 194.81 kB | | dc-polyfill | 0.1.11 | 25.74 kB | 25.74 kB |🤖 This report was automatically generated by heaviest-objects-in-the-universe |
🎉 All green!🧪 All tests passed 🎯 Code Coverage (details) 🔗 Commit SHA: 232a685 | Docs | Datadog PR Page | Give us feedback! |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #9105 +/- ##
=======================================
Coverage 93.69% 93.69%
=======================================
Files 889 889
Lines 50856 50856
Branches 11830 11830
=======================================
+ Hits 47647 47649 +2
+ Misses 3209 3207 -2 Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
BenchmarksBenchmark execution time: 2026-06-27 16:49:26 Comparing candidate commit 232a685 in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 2253 metrics, 33 unstable metrics.
|
…on fixture (#9105) The ESM integration fixture connected with no client-side timeout, so a stalled Oracle round-trip hung the subprocess until the 20s mocha per-test timeout fired with no diagnosable error. CI hit this intermittently: five of six sibling ESM subprocesses connected and ran the query in ~0.5s while one wedged for the full window. connect_timeout bounds the connect phase and callTimeout bounds each query round-trip, so a stalled session now throws (NJS-123 / a connect error) well inside the budget and the test fails fast and attributable instead of as a generic timeout. Refs: oracle/node-oracledb#1592
…on fixture (#9105) The ESM integration fixture connected with no client-side timeout, so a stalled Oracle round-trip hung the subprocess until the 20s mocha per-test timeout fired with no diagnosable error. CI hit this intermittently: five of six sibling ESM subprocesses connected and ran the query in ~0.5s while one wedged for the full window. connect_timeout bounds the connect phase and callTimeout bounds each query round-trip, so a stalled session now throws (NJS-123 / a connect error) well inside the budget and the test fails fast and attributable instead of as a generic timeout. Refs: oracle/node-oracledb#1592
…on fixture (#9105) The ESM integration fixture connected with no client-side timeout, so a stalled Oracle round-trip hung the subprocess until the 20s mocha per-test timeout fired with no diagnosable error. CI hit this intermittently: five of six sibling ESM subprocesses connected and ran the query in ~0.5s while one wedged for the full window. connect_timeout bounds the connect phase and callTimeout bounds each query round-trip, so a stalled session now throws (NJS-123 / a connect error) well inside the budget and the test fails fast and attributable instead of as a generic timeout. Refs: oracle/node-oracledb#1592
Summary
The ESM integration fixture (
server.mjs) connected with no client-side timeout, so a stalled Oracle round-trip hung the subprocess until the 20s mocha per-test timeout fired with no diagnosable error. CI hit this intermittently — five of six sibling ESM subprocesses connected and ran the query in ~0.5s while one wedged for the full window, surfacing asError: Timeout of 20000ms exceededwith no attribution.connect_timeoutbounds the connect phase andconnection.callTimeoutbounds each query round-trip, so a stalled session now throws (NJS-123for a wedged round-trip, a connect error for a wedged connect) well inside the test budget. A flake becomes a fast, attributable failure.Test plan
Refs: oracle/node-oracledb#1592