[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: @yangzhang75
  You can notify them by mentioning @yangzhang75 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?