fix(amber): add timeout and retry to dataset file-service requests

[Ma77Ball]

What changes were proposed in this PR?

• Route DatasetFileDocument's presigned-URL fetch and file download through a requests.Session configured with a (5s connect, 10s read) timeout, so a hung or unreachable file-service fails in bounded time instead of blocking the worker thread forever. The read timeout bounds inactivity between bytes, not the total download time, so large dataset files that stream steadily are unaffected; it only trips when the connection stalls for 10s with no data.
• Mount a urllib3 Retry policy on the session (3 retries, exponential backoff, retrying on connection errors and 5xx). Both calls are idempotent GETs, so the retry set is restricted to GET.
• Translate network failures (connect/read timeouts and connection errors, including those surfaced after retries are exhausted) into RuntimeError, consistent with the module's existing failure handling, so callers get a uniform error contract instead of a raw requests/urllib3 exception.

Any related issues, documentation, discussions?

Closes: #5666

How was this PR tested?

• Added pytest coverage in test_dataset_file_document.py (26 tests):
  • asserts the (connect, read) timeout tuple is passed on both the presigned-URL request and the file download;
  • asserts the retry adapter is mounted for http:// and https:// with the expected policy (total=3, connect=3, read=3, backoff_factor=0.5, status_forcelist={500,502,503,504}, GET-only);
  • asserts a ReadTimeout / ConnectionError is wrapped in RuntimeError on both code paths.
• ruff check and ruff format --check pass on the modified files.

Was this PR authored or co-authored using generative AI tooling?

Co-authored with Claude Opus 4.8 in compliance with ASF

[github-actions]

⚠️ Benchmark changes need a look

🟢 4 better · 🔴 5 worse · ⚪ 6 noise (<±5%) · 0 without baseline

Compared against main 6d31f46 benchmarked on this same runner, so the delta is largely free of cross-runner hardware noise. The "7d avg" column still reflects the gh-pages dashboard. Treat <±5% as noise unless repeated.

Dashboard · Run

	config	throughput	MB/s	latency	max Δ latest / 7d
🔴	bs=10 sw=10 sl=64	442	0.27	21,999/34,024/34,024 us	🔴 +10.5% / 🟢 +7.7%
🟢	bs=100 sw=10 sl=64	976	0.596	101,476/122,445/122,445 us	🟢 -24.5% / 🟢 -12.4%
⚪	bs=1000 sw=10 sl=64	1,090	0.665	918,447/962,800/962,800 us	⚪ within ±5% / 🟢 -5.9%

Baseline details

Latest main 6d31f46 from same runner

config	metric	PR	latest main	7d avg	Δ latest	Δ 7d
bs=10 sw=10 sl=64	throughput	442 tuples/sec	474 tuples/sec	410.82 tuples/sec	-6.8%	+7.6%
bs=10 sw=10 sl=64	MB/s	0.27 MB/s	0.29 MB/s	0.251 MB/s	-6.9%	+7.7%
bs=10 sw=10 sl=64	p50	21,999 us	19,899 us	23,785 us	+10.5%	-7.5%
bs=10 sw=10 sl=64	p95	34,024 us	30,980 us	34,980 us	+9.8%	-2.7%
bs=10 sw=10 sl=64	p99	34,024 us	30,980 us	34,980 us	+9.8%	-2.7%
bs=100 sw=10 sl=64	throughput	976 tuples/sec	922 tuples/sec	891.94 tuples/sec	+5.9%	+9.4%
bs=100 sw=10 sl=64	MB/s	0.596 MB/s	0.563 MB/s	0.544 MB/s	+5.9%	+9.5%
bs=100 sw=10 sl=64	p50	101,476 us	101,002 us	112,277 us	+0.5%	-9.6%
bs=100 sw=10 sl=64	p95	122,445 us	162,089 us	139,802 us	-24.5%	-12.4%
bs=100 sw=10 sl=64	p99	122,445 us	162,089 us	139,802 us	-24.5%	-12.4%
bs=1000 sw=10 sl=64	throughput	1,090 tuples/sec	1,120 tuples/sec	1,041 tuples/sec	-2.7%	+4.7%
bs=1000 sw=10 sl=64	MB/s	0.665 MB/s	0.684 MB/s	0.635 MB/s	-2.8%	+4.7%
bs=1000 sw=10 sl=64	p50	918,447 us	894,742 us	972,714 us	+2.6%	-5.6%
bs=1000 sw=10 sl=64	p95	962,800 us	920,898 us	1,023,057 us	+4.6%	-5.9%
bs=1000 sw=10 sl=64	p99	962,800 us	920,898 us	1,023,057 us	+4.6%	-5.9%

Raw CSV

config_idx,batch_size,schema_width,string_len,num_batches,total_ms,total_tuples,total_bytes,tuples_per_sec,mb_per_sec,lat_p50_us,lat_p95_us,lat_p99_us
0,10,10,64,20,452.08,200,128000,442,0.270,21998.52,34024.01,34024.01
1,100,10,64,20,2049.69,2000,1280000,976,0.596,101475.87,122445.33,122445.33
2,1000,10,64,20,18356.29,20000,12800000,1090,0.665,918447.28,962800.02,962800.02

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 53.49%. Comparing base (6d31f46) to head (00672b7).

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #5667      +/-   ##
============================================
- Coverage     53.86%   53.49%   -0.37%     
+ Complexity     2756     2696      -60     
============================================
  Files          1099     1099              
  Lines         42541    42649     +108     
  Branches       4577     4577              
============================================
- Hits          22916    22817      -99     
- Misses        18290    18502     +212     
+ Partials       1335     1330       -5     

Flag	Coverage Δ		*Carryforward flag
access-control-service	70.44% <ø> (ø)		Carriedforward from 44b894a
agent-service	34.36% <ø> (ø)		Carriedforward from 44b894a
amber	54.04% <ø> (-1.16%)	⬇️	Carriedforward from 44b894a
computing-unit-managing-service	1.65% <ø> (ø)		Carriedforward from 44b894a
config-service	56.71% <ø> (ø)		Carriedforward from 44b894a
file-service	57.06% <ø> (ø)		Carriedforward from 44b894a
frontend	48.02% <ø> (-0.03%)	⬇️	Carriedforward from 44b894a
pyamber	91.07% <100.00%> (+0.93%)	⬆️
python	90.80% <ø> (-0.01%)	⬇️	Carriedforward from 44b894a
workflow-compiling-service	58.69% <ø> (ø)		Carriedforward from 44b894a

*This pull request uses carry forward flags. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Ma77Ball]

@Yicong-Huang would you be able to review this when you get a chance? It hardens DatasetFileDocument's file-service requests with bounded timeouts, GET-only retries, and uniform RuntimeError failures (you authored this module originally, so you have the most context here). Thanks!

[Yicong-Huang]

Sure. Adding @bobbai00 as well PTAL

[Yicong-Huang]

LGTM in general, please see inline comments

[bobbai00]

LGTM.

[bobbai00]

The PR description says (10s connect, 60s read), but the code sets (5s connect, 10s read):

_CONNECT_TIMEOUT_SECONDS = 5
_READ_TIMEOUT_SECONDS = 10

The actual values are reasonable — could you update the description to match? A note that the 10s read timeout bounds inactivity-between-bytes (not total download time) would also help future readers
understand why it's safe for large dataset files.

[Ma77Ball]

Updated the description to match the code's (5s connect, 10s read) and added a note clarifying the read timeout bounds inactivity between bytes (not total download time), so it's safe for large dataset files.

[Ma77Ball]

@Yicong-Huang or @bobbai00, can you merge this pr?

[chenlica]

@Yicong-Huang and @bobbai00?

[github-actions]

Backport to release/v1.2 succeeded as 50051ad. Run