chore(amber): remove unused actor helpers, an unreferenced RPC sentinel and four unreachable guards

[aglinxinyuan]

What changes were proposed in this PR?

Removes six unreachable or unused regions in amber. 46 lines deleted, 2 inserted across 7 files. Every claim was verified by grep across all file types, including the Python side and .proto files where an RPC constant could plausibly be mirrored.

Removed	Evidence
PekkoActorService.sendToSelfOnce, ask	zero call sites; ask's only other hit is the pekko.pattern.ask inside its own body
AsyncRPCClient.IgnoreReply = -1	unreferenced; every other hit is the distinct IgnoreReplyAndDoNotLog = -2
ExecutionResultService's case _ => throw	WebOutputMode is sealed abstract with exactly three final case class subtypes, all matched above
UserQuotaResource's executions == null	jOOQ fetch() returns a non-null Result; simplified to isEmpty
ResultExportService's zipStream == null	exportOperatorsAsZip either throws or returns a new StreamingOutput { … } literal
WorkflowService.lastCompletedLogicalPlan	write-only var: declaration, one write, zero readers

Checks that changed the outcome

Subclasses, not just call sites. Three test classes extend PekkoActorService, so a plain call-site grep would not have been enough. Their overrides are sendToSelfWithFixedDelay (CoordinatorTimerServiceSpec.scala:420) and scheduleWithFixedDelay (PekkoMessageTransferServiceSpec.scala:209) — neither of the removed members.

The Python side and the proto. IgnoreReply could have been mirrored in the Python worker or as a proto sentinel. It is not: grep -rni "ignore_reply|ignorereply|do_not_log" over amber/src/main/python and src/test/python returns nothing, and commandId is a plain int64 field in controlcommands.proto / controlreturns.proto with no named sentinel. No literal -1 is used as a commandId anywhere in amber/src.

Exhaustivity was confirmed by the compiler, not by reading. Removing the case _ arm produced no match may not be exhaustive warning, and the total warning count is unchanged from the pre-edit baseline (8 test-compile warnings before and after, all pre-existing and in unrelated files).

The sibling guard is genuinely live. ResultExportService has a second == null guard on the adjacent path; exportOperatorResultAsStream really can return null, and two ResultExportServiceSpec tests assert the error it raises. That one is untouched.

One judgement call worth reviewing

For lastCompletedLogicalPlan I removed the whole enclosing executionService.subscribe { … registerDiffHandler { … } } block rather than only the assignment. With the write gone the handler body reduces to Iterable.empty, and StateStore.registerDiffHandler appends to diffHandlers rather than replacing, so dropping a handler that emits nothing is behaviour-preserving. It also disposes of a Disposable that was previously being discarded. WorkflowServiceSpec's own doc-comment described the var "and the constructor's executionService.subscribe block that maintains it" as one unit that "should be deleted instead", so this follows the documented intent — but it is the one change here that is more than a strict deletion, so it deserves a look.

Orphaned imports were removed with each deletion (FutureBijection._, COMPLETED, LogicalPlan), since amber sets -Ywarn-unused:imports.

No tests were removed

No spec exercised any deleted member. One stale 6-line "Deliberately not covered" comment in WorkflowServiceSpec documented code that no longer exists, so it is gone; the tests around it are untouched.

Verification

• WorkflowExecutionService/Test/compile succeeds with the warning count identical to baseline — no new exhaustivity or unused-import warnings.
• The 10 affected suites run green: Suites completed 10, aborted 0; Tests succeeded 153, failed 0. Re-verified independently at 6 suites / 119 tests.
• scalafmtCheck (276 sources), Test/scalafmtCheck (202 sources) and scalafixAll --check across the whole build all pass.
• Residual-reference greps for every removed symbol come back empty.

Deliberately left alone

Two nearby findings are behavioural questions rather than cleanups, and are not touched here:

• WorkerTimerService.resumeAdaptiveBatching is a permanent no-op. pauseAdaptiveBatching has no call sites, and isPaused is only ever set true inside it — so the live resumeAdaptiveBatching (called from ResumeHandler.scala:44) resumes from a state nothing can enter. Whether pause was meant to be wired into PauseHandler needs a maintainer's call.
• WorkflowExecution.getState's READY arm is unreachable, because ExecutionUtils.aggregateStates folds its all-ready case into RUNNING and never returns READY. Whether that aggregation is intended is likewise not a cleanup decision.

Any related issues, documentation, discussions?

Closes #7784

How was this PR tested?

STORAGE_ICEBERG_CATALOG_TYPE=postgres sbt "WorkflowExecutionService/testOnly org.apache.texera.amber.engine.architecture.common.PekkoActorRefMappingServiceSpec org.apache.texera.amber.engine.common.rpc.AsyncRPCClientSpec org.apache.texera.web.service.ExecutionResultServiceSpec org.apache.texera.web.resource.dashboard.user.quota.UserQuotaResourceSpec org.apache.texera.web.service.ResultExportServiceSpec org.apache.texera.web.service.WorkflowServiceSpec"

[info] Suites: completed 6, aborted 0
[info] Tests: succeeded 119, failed 0, canceled 0, ignored 0, pending 0

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

Generated-by: Claude Code (Opus 5)

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[github-actions]

Automated Reviewer Suggestions

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

• Contributors with relevant context: @mengw15, @Yicong-Huang
  You can notify them by mentioning @mengw15, @Yicong-Huang in a comment.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.25%. Comparing base (bf0e777) to head (e43ec33).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #7785      +/-   ##
============================================
+ Coverage     91.24%   91.25%   +0.01%     
- Complexity     4468     4469       +1     
============================================
  Files          1171     1171              
  Lines         47115    47107       -8     
  Branches       5286     5285       -1     
============================================
- Hits          42991    42989       -2     
+ Misses         2448     2444       -4     
+ Partials       1676     1674       -2     

Flag	Coverage Δ		*Carryforward flag
access-control-service	81.00% <ø> (ø)		Carriedforward from bf0e777
agent-service	98.62% <ø> (ø)		Carriedforward from bf0e777
amber	88.02% <100.00%> (+0.02%)	⬆️
computing-unit-managing-service	73.67% <ø> (ø)		Carriedforward from bf0e777
config-service	86.73% <ø> (ø)		Carriedforward from bf0e777
file-service	68.90% <ø> (ø)		Carriedforward from bf0e777
frontend	92.63% <ø> (ø)		Carriedforward from bf0e777
notebook-migration-service	83.74% <ø> (ø)		Carriedforward from bf0e777
pyamber	97.57% <ø> (ø)		Carriedforward from bf0e777
workflow-compiling-service	77.19% <ø> (ø)		Carriedforward from bf0e777

*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

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

Compared against main bf0e777 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	392	0.239	26,317/34,679/34,679 us	🔴 +15.9% / 🔴 +113.8%
⚪	bs=100 sw=10 sl=64	779	0.476	125,332/163,876/163,876 us	⚪ within ±5% / 🔴 +47.6%
🔴	bs=1000 sw=10 sl=64	896	0.547	1,096,465/1,208,936/1,208,936 us	🔴 +6.1% / 🔴 +14.5%

Baseline details

Latest main bf0e777 from same runner

config	metric	PR	latest main	7d avg	Δ latest	Δ 7d
bs=10 sw=10 sl=64	throughput	392 tuples/sec	397 tuples/sec	743.3 tuples/sec	-1.3%	-47.3%
bs=10 sw=10 sl=64	MB/s	0.239 MB/s	0.242 MB/s	0.454 MB/s	-1.2%	-47.3%
bs=10 sw=10 sl=64	p50	26,317 us	22,714 us	13,204 us	+15.9%	+99.3%
bs=10 sw=10 sl=64	p95	34,679 us	36,163 us	16,220 us	-4.1%	+113.8%
bs=10 sw=10 sl=64	p99	34,679 us	36,163 us	19,867 us	-4.1%	+74.6%
bs=100 sw=10 sl=64	throughput	779 tuples/sec	819 tuples/sec	959.52 tuples/sec	-4.9%	-18.8%
bs=100 sw=10 sl=64	MB/s	0.476 MB/s	0.5 MB/s	0.586 MB/s	-4.8%	-18.7%
bs=100 sw=10 sl=64	p50	125,332 us	121,079 us	103,974 us	+3.5%	+20.5%
bs=100 sw=10 sl=64	p95	163,876 us	165,320 us	111,036 us	-0.9%	+47.6%
bs=100 sw=10 sl=64	p99	163,876 us	165,320 us	118,982 us	-0.9%	+37.7%
bs=1000 sw=10 sl=64	throughput	896 tuples/sec	912 tuples/sec	994.68 tuples/sec	-1.8%	-9.9%
bs=1000 sw=10 sl=64	MB/s	0.547 MB/s	0.557 MB/s	0.607 MB/s	-1.8%	-9.9%
bs=1000 sw=10 sl=64	p50	1,096,465 us	1,095,811 us	1,011,206 us	+0.1%	+8.4%
bs=1000 sw=10 sl=64	p95	1,208,936 us	1,139,965 us	1,055,603 us	+6.1%	+14.5%
bs=1000 sw=10 sl=64	p99	1,208,936 us	1,139,965 us	1,084,808 us	+6.1%	+11.4%

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,510.04,200,128000,392,0.239,26317.48,34678.99,34678.99
1,100,10,64,20,2565.98,2000,1280000,779,0.476,125331.50,163875.60,163875.60
2,1000,10,64,20,22314.13,20000,12800000,896,0.547,1096464.82,1208935.75,1208935.75