fix(admin/updates): match the current ctx.NotFound signature

[rg4444]

fix(admin/updates): match the current ctx.NotFound signature

The v0.1.1 build failed at step #9 (Build & push Docker image) with three identical compile errors in routers/web/admin/updates.go (the Slice 4 handler added in #136):

routers/web/admin/updates.go:263:3: too many arguments in call to ctx.NotFound
routers/web/admin/updates.go:269:3: too many arguments in call to ctx.NotFound
routers/web/admin/updates.go:276:3: too many arguments in call to ctx.NotFound

Root cause

I matched the older two-argument Gitea pattern (NotFound(logMsg string, logErr error)) from memory. This fork's current signature in services/context/context_response.go is single-arg:

func (ctx *Context) NotFound(logErr error)

Fix

Drop the first string argument from all three call sites:

-ctx.NotFound("UpdateJobView", errors.New("missing job id"))
+ctx.NotFound(errors.New("missing job id"))

-ctx.NotFound("UpdateJobView", errors.New("updater not configured"))
+ctx.NotFound(errors.New("updater not configured"))

-ctx.NotFound("UpdateJobView", err)
+ctx.NotFound(err)

Behaviour is unchanged — NotFound still logs the underlying error.

Pattern verified against the existing codebase

routers/web/shared/packages/packages.go:217:    ctx.NotFound(err)
routers/web/shared/actions/runners.go:248:      ctx.NotFound(util.NewPermissionDeniedErrorf(...))
routers/web/shared/actions/runners.go:355:      ctx.NotFound(errors.New("runner not found"))

How this was diagnosed without log access

The Azure blob storage that hosts GHA job logs isn't in my sandbox's outbound allowlist, so I couldn't read logs directly. Pivoted to the check-runs annotations API:

GET /repos/{owner}/{repo}/check-runs/{check_id}/annotations

That returned the three compile errors with file/line specifics, which is more than enough to fix. Adding this to my mental toolbox for future debugging — annotations are often the cleanest signal even when logs aren't reachable.

After merge

Same dance as v0.1.0 had: delete v0.1.1 ref, recreate against new main HEAD, workflow re-fires. Wall clock should be even faster than v0.1.0 because the v0.1.1 failed run still warmed the buildx cache for the build step — the failed step was the build itself, but the partial buildx layers up to the compile point are cached. Expected ~2-4 min for the retry.

Diff

 routers/web/admin/updates.go | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)