Build detail page shows "Page not found" (404) for webhook- and API-triggered (and finished) deployments

[onerandomd3v]

Build detail page shows "Page not found" (404) for webhook- and API-triggered (and finished) deployments

Environment

• Openship 0.6.6, self-hosted (Docker Compose mode)
• Deployments triggered via the GitHub App webhook (auto-deploy on push) and via the API (POST /api/deployments/build/access), rather than through the dashboard deploy wizard.

Summary

Opening a deployment's build page (/build/{deploymentId}) renders a "Page not found" (404) for deployments that were not initiated through the dashboard's interactive deploy/build wizard — i.e. webhook (auto-deploy) and API-triggered deployments — as well as for builds that have already finished. The underlying deployment record and its build logs are persisted and remain fully accessible via the API (GET /api/deployments/{id} and GET /api/deployments/{id}/logs both return the status and full logs), so this appears to be a dashboard rendering gap rather than missing data.

(Confirmed on 0.6.6: navigating to /build/{id} for a ready deployment with trigger: webhook renders the app's "Page not found" 404 page with "Back to dashboard" / "View deployments" buttons — screenshot attached.)

Steps to reproduce

1. Configure a project with auto-deploy on push (GitHub App), or deploy a project via POST /api/deployments/build/access directly.
2. Trigger a deployment via a git push (webhook) or the API call — not through the dashboard wizard.
3. In the dashboard, open that deployment's build page (e.g. click the build, or navigate to /build/{deploymentId}).

Expected

The build page shows the deployment's status and logs for any deployment, regardless of how it was triggered or whether it is still running — falling back to the persisted deployment record + stored build logs when there is no live build session/stream to attach to.

Actual

The page renders ResourceNotFound (a 404-style page). It happens for webhook/API-triggered deployments and for deployments whose build has already completed.

Likely cause (from the source)

In apps/dashboard/src/app/(dashboard)/(deployment)/build/[id]/page.tsx, the page initializes a build session: if the deployment is currently deploying it attaches to the live stream (GET /:id/stream), otherwise it calls loadBuildSession(deploymentId) (from useDeploymentBuild / DeploymentContext). When no build session can be loaded/attached, the page sets notFound and renders ResourceNotFound.

Deployments created outside the dashboard wizard (webhook/API), and finished builds, don't have a loadable/attachable build session, so the page shows not-found — even though GET /api/deployments/{id} and GET /api/deployments/{id}/logs return the persisted status and logs.

Suggested fix

When loadBuildSession finds no live/attachable session, fall back to rendering the persisted deployment record and its stored logs (from the deployment + logs endpoints) instead of showing ResourceNotFound. This makes the build page work for all deployment triggers (wizard, webhook auto-deploy, API) and for completed builds.

Impact / severity

Low severity — no data is lost; status and logs remain accessible via the API. It is a dashboard UX gap that becomes more visible as webhook auto-deploy usage grows (which is the common path once the GitHub App is connected), since those deployments are the ones most likely to hit it.

[onerandomd3v]

Two more dashboard-state observations in the same family as this issue (the UI not reflecting the real state of webhook/API-driven projects), on self-hosted 0.6.6:

1. Overview tab shows auto-deploy as "off" even though it's enabled and working

For projects where auto-deploy was enabled via the API (POST /api/projects/:id/auto-deploy → { success: true, auto_deploy: true, webhook_strategy: "repo" }), pushes do trigger deploys (confirmed — the push webhook handler reads project.auto_deploy, which is true), but the dashboard Overview shows auto-deploy as off.

Root cause looks like two endpoints disagreeing:

• GET /api/projects/:id → autoDeploy: true (and the DB column project.auto_deploy is true)
• GET /api/projects/:id/git → auto_deploy: null, webhook_active: null

OverviewTab.tsx renders active={!!gitData?.autoDeployEnabled} (from the git endpoint, which is null), while GitInfo.tsx reads projectData?.auto_deploy (the real, true value). So the toggle and the Overview can disagree, and the git endpoint under-reports the state that actually governs auto-deploy.

Expected: the dashboard should reflect project.auto_deploy consistently, so a project whose pushes deploy isn't shown as "auto-deploy off."

2. (Question, not a bug) Deploy status on GitHub PRs

Self-hosted Openship triggers deploys via a push webhook but doesn't post any status back to the PR (no commit status / Checks entry), so a deploy is invisible on the PR thread. Is surfacing deploy status on PRs (via the Checks/Deployments API) something the GitHub App supports or is on the roadmap? Not blocking — just noting the difference vs managed platforms.

[niveshsaharan]

I'm getting the same issue.

[Hydralerne]

fixed in 0.6.7, sorry