[ShawnGarello]

What changes were proposed in this PR?

Opening a hub link to a workflow that was deleted or made private makes GET /api/workflow/publicised/{wid} fail with a 500.

retrievePublicWorkflow dereferenced the row from fetchOne() without a null check. It now answers 404, the same guard getWorkflowType already has. A private workflow gets the same 404 as a missing one, as the query (wid = ? AND is_public) already treats them alike. The hub page shows the same load error either way; what changes is the status code, and the server log no longer gets a NullPointerException stack trace.

Two regression tests in WorkflowResourceSpec, under their own retrievePublicWorkflow subject: a private workflow, and a wid that does not exist. The public case is already covered by the makePublic and default-view tests.

This picks up #8140 by @carloea2, which was closed unmerged; it applies the review on that PR (braces, the test under its own subject, the title).

Any related issues, documentation, discussions?

Closes #8139

Backport: the same unguarded fetchOne() is on release/v1.3 and release/v1.2, but the code after it differs there (no publicCopyOf), so the cherry-pick may need the guard re-applied by hand. WorkflowResourceSpec.scala exists on both branches.

How was this PR tested?

With Postgres up, sbt -batch "WorkflowExecutionService/testOnly *WorkflowResourceSpec":

1. Red: the first commit adds only the two tests. 79 pass, 2 fail: exactly those two, each with a NullPointerException instead of NotFoundException.
2. Green: with the guard, 81 pass, 0 fail (run twice). testOnly *WorkflowResourceSpec *WorkflowPublishSpec (the other spec that calls the method): 135 pass, 0 fail.
3. With only the guard reverted, exactly the two new tests fail again with NullPointerException.
4. sbt scalafmtCheckAll "scalafixAll --check" is clean.

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

Generated-by: Claude Code (Opus 5.5)

[ShawnGarello]

/request-review @Yicong-Huang

[github-actions]

Backport auto-label report

This fix: PR was checked against each actively-supported release branch. A release/* label nominates a backport target; the branch's release manager approving this PR is what sends the fix there. The required Backport Approvals check stays red until every label below is approved, so each manager either approves or removes their own label — which is why the labels left on a merged PR are exactly the branches it reached.

Release branch	Analysis
✅ release/v1.3	Change detected on this branch — label added; this fix is queued to backport here. @mengw15 decides: approving sends the fix here, removing this label declines it. The merge waits on one or the other. Review requested.
✅ release/v1.2	Change detected on this branch — label added; this fix is queued to backport here. @xuang7 decides: approving sends the fix here, removing this label declines it. The merge waits on one or the other. Review requested.

Auto-label run.

[github-actions]

Automated Reviewer Suggestions

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

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

[Yicong-Huang]

🟢 0 must-fix · 0 advisory · 0 polish: small, peer-consistent guard that returns 404 instead of 500 for unavailable public workflows.

Verification trace

Checked the changed public endpoint (GET /api/workflow/publicised/{wid}) against its sibling public endpoints: the IS_PUBLIC filter in the query is the access control, so private and missing workflows return the same 404 and no existence oracle is created, and wid reaches the database only through parameterized jOOQ. The other fetchOne() dereferences in the dashboard resources are guarded or non-nullable (Option-wrapped, getOrElse throwing NotFoundException, or INSERT ... RETURNING), so this was the only unguarded one.

[ShawnGarello]

Thanks @Yicong-Huang! @mengw15 @xuang7, could you decide on the release/v1.3 and release/v1.2 labels when you have a chance?

[mengw15]

Dropped the backport labels — not a regression: retrievePublicWorkflow was unguarded from #2873 onward, and #3252 only moved it. Same call as #8384. Still worth having on main.

[ShawnGarello]

Updated the branch now that #9100 fixed CI. @Yicong-Huang, could you approve the workflow runs when you have a chance?

[github-actions]

⚠️ Benchmark changes need a look

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

Compared against main 1299992 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	511	0.312	19,076/26,017/26,017 us	🔴 +11.7% / 🔴 +112.8%
🟢	bs=100 sw=10 sl=64	1,238	0.756	79,818/92,664/92,664 us	🟢 -17.3% / 🟢 -13.1%
🔴	bs=1000 sw=10 sl=64	1,438	0.878	685,029/783,556/783,556 us	🔴 +7.0% / 🟢 -12.2%

Baseline details

Latest main 1299992 from same runner

config	metric	PR	latest main	7d avg	Δ latest	Δ 7d
bs=10 sw=10 sl=64	throughput	511 tuples/sec	519 tuples/sec	1,019 tuples/sec	-1.5%	-49.9%
bs=10 sw=10 sl=64	MB/s	0.312 MB/s	0.317 MB/s	0.622 MB/s	-1.6%	-49.8%
bs=10 sw=10 sl=64	p50	19,076 us	17,085 us	10,144 us	+11.7%	+88.0%
bs=10 sw=10 sl=64	p95	26,017 us	28,527 us	12,225 us	-8.8%	+112.8%
bs=10 sw=10 sl=64	p99	26,017 us	28,527 us	15,527 us	-8.8%	+67.6%
bs=100 sw=10 sl=64	throughput	1,238 tuples/sec	1,189 tuples/sec	1,371 tuples/sec	+4.1%	-9.7%
bs=100 sw=10 sl=64	MB/s	0.756 MB/s	0.725 MB/s	0.837 MB/s	+4.3%	-9.7%
bs=100 sw=10 sl=64	p50	79,818 us	83,225 us	79,910 us	-4.1%	-0.1%
bs=100 sw=10 sl=64	p95	92,664 us	111,987 us	87,155 us	-17.3%	+6.3%
bs=100 sw=10 sl=64	p99	92,664 us	111,987 us	106,643 us	-17.3%	-13.1%
bs=1000 sw=10 sl=64	throughput	1,438 tuples/sec	1,427 tuples/sec	1,415 tuples/sec	+0.8%	+1.6%
bs=1000 sw=10 sl=64	MB/s	0.878 MB/s	0.871 MB/s	0.864 MB/s	+0.8%	+1.6%
bs=1000 sw=10 sl=64	p50	685,029 us	700,484 us	780,407 us	-2.2%	-12.2%
bs=1000 sw=10 sl=64	p95	783,556 us	732,343 us	817,814 us	+7.0%	-4.2%
bs=1000 sw=10 sl=64	p99	783,556 us	732,343 us	848,683 us	+7.0%	-7.7%

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,391.54,200,128000,511,0.312,19075.65,26017.17,26017.17
1,100,10,64,20,1615.35,2000,1280000,1238,0.756,79818.06,92664.40,92664.40
2,1000,10,64,20,13909.17,20000,12800000,1438,0.878,685029.03,783555.98,783555.98

[ShawnGarello]

CI is green now. @Yicong-Huang, could you merge this when you have a chance? Thanks!