chore(pyamber): interpolate the offending type in the BATCH_SIZE validation error

[eugenegujing]

What changes were proposed in this PR?

When a user sets a non-integer BATCH_SIZE on a Python BatchOperator, the validation error they get back is the template text itself:

BATCH_SIZE cannot be {type(value))}.

The string literal in BatchOperator._validate_batch_size (amber/src/main/python/core/models/operator.py) is missing the f prefix, so {type(value)} is never interpolated and it additionally contains a stray ) inside the braces. The type of the supplied value is exactly the piece of information the message is meant to convey, so as written the error tells the user nothing about what they did wrong.

This PR corrects both defects in one line:

raise ValueError(f"BATCH_SIZE cannot be {type(value)}.")

so the user now sees, e.g., BATCH_SIZE cannot be <class 'float'>. The wording is kept consistent with the sibling messages in the same validator (BATCH_SIZE cannot be None.).

Any related issues, documentation, discussions?

Closes #7565

How was this PR tested?

Three tests were added to the existing TestBatchOperatorValidation class in amber/src/test/python/core/models/test_operator.py, pinning the exact message by string equality:

• _validate_batch_size(10.0) raises ValueError with message BATCH_SIZE cannot be <class 'float'>.
• _validate_batch_size("10") raises ValueError with message BATCH_SIZE cannot be <class 'str'>.
• constructing a concrete BatchOperator subclass with BATCH_SIZE = 10.0 raises the same float message end-to-end.

Full run: cd amber && pytest src/test/python/core/models/test_operator.py — 32 passed. ruff check and ruff format --check pass on src/main/python and src/test/python (the same commands CI runs).

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

Co-authred by: Claude Code (Claude Fable 5)

[github-actions]

Automated Reviewer Suggestions

Based on the git blame history of the changed files, we recommend the following reviewers:

• Contributors with relevant context: @aglinxinyuan, @Ma77Ball
  You can notify them by mentioning @aglinxinyuan, @Ma77Ball in a comment.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.39%. Comparing base (42d08a3) to head (ebe1d7b).
⚠️ Report is 17 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##               main    #7570   +/-   ##
=========================================
  Coverage     86.38%   86.39%           
  Complexity     4211     4211           
=========================================
  Files          1169     1169           
  Lines         46750    46784   +34     
  Branches       5203     5203           
=========================================
+ Hits          40387    40418   +31     
- Misses         4641     4644    +3     
  Partials       1722     1722           

Flag	Coverage Δ		*Carryforward flag
access-control-service	70.00% <ø> (ø)		Carriedforward from 42d08a3
agent-service	86.87% <ø> (ø)		Carriedforward from 42d08a3
amber	81.87% <ø> (ø)		Carriedforward from 42d08a3
computing-unit-managing-service	50.72% <ø> (ø)		Carriedforward from 42d08a3
config-service	65.97% <ø> (ø)		Carriedforward from 42d08a3
file-service	69.05% <ø> (ø)		Carriedforward from 42d08a3
frontend	89.23% <ø> (ø)		Carriedforward from 42d08a3
notebook-migration-service	78.89% <ø> (ø)		Carriedforward from 42d08a3
pyamber	97.52% <100.00%> (-0.05%)	⬇️
workflow-compiling-service	26.31% <ø> (ø)		Carriedforward from 42d08a3

*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.

[github-actions]

⚠️ Benchmark changes need a look

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

Compared against main e878df3 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	438	0.268	22,492/28,726/28,726 us	🟢 -10.1% / 🔴 +79.6%
🟢	bs=100 sw=10 sl=64	951	0.58	104,631/123,723/123,723 us	🟢 -15.5% / 🔴 +14.5%
⚪	bs=1000 sw=10 sl=64	1,121	0.684	897,078/950,156/950,156 us	⚪ within ±5% / 🟢 -11.1%

Baseline details

Latest main e878df3 from same runner

config	metric	PR	latest main	7d avg	Δ latest	Δ 7d
bs=10 sw=10 sl=64	throughput	438 tuples/sec	467 tuples/sec	784.3 tuples/sec	-6.2%	-44.2%
bs=10 sw=10 sl=64	MB/s	0.268 MB/s	0.285 MB/s	0.479 MB/s	-6.0%	-44.0%
bs=10 sw=10 sl=64	p50	22,492 us	21,607 us	12,590 us	+4.1%	+78.6%
bs=10 sw=10 sl=64	p95	28,726 us	31,963 us	15,991 us	-10.1%	+79.6%
bs=10 sw=10 sl=64	p99	28,726 us	31,963 us	18,694 us	-10.1%	+53.7%
bs=100 sw=10 sl=64	throughput	951 tuples/sec	942 tuples/sec	1,002 tuples/sec	+1.0%	-5.1%
bs=100 sw=10 sl=64	MB/s	0.58 MB/s	0.575 MB/s	0.612 MB/s	+0.9%	-5.2%
bs=100 sw=10 sl=64	p50	104,631 us	104,679 us	101,285 us	-0.0%	+3.3%
bs=100 sw=10 sl=64	p95	123,723 us	146,370 us	108,068 us	-15.5%	+14.5%
bs=100 sw=10 sl=64	p99	123,723 us	146,370 us	118,235 us	-15.5%	+4.6%
bs=1000 sw=10 sl=64	throughput	1,121 tuples/sec	1,119 tuples/sec	1,030 tuples/sec	+0.2%	+8.8%
bs=1000 sw=10 sl=64	MB/s	0.684 MB/s	0.683 MB/s	0.629 MB/s	+0.1%	+8.8%
bs=1000 sw=10 sl=64	p50	897,078 us	899,712 us	991,882 us	-0.3%	-9.6%
bs=1000 sw=10 sl=64	p95	950,156 us	940,496 us	1,038,496 us	+1.0%	-8.5%
bs=1000 sw=10 sl=64	p99	950,156 us	940,496 us	1,068,265 us	+1.0%	-11.1%

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,456.29,200,128000,438,0.268,22491.61,28725.82,28725.82
1,100,10,64,20,2103.58,2000,1280000,951,0.580,104631.10,123722.59,123722.59
2,1000,10,64,20,17841.11,20000,12800000,1121,0.684,897077.67,950156.44,950156.44