Invalid parameters on /artifact-files endpoint causes argo server to panic #12542
Description
Pre-requisites
- I have double-checked my configuration
- I can confirm the issue exists when I tested with
:latest - I have searched existing issues and could not find a match for this bug
- I'd like to contribute the fix myself (see contributing guide)
What happened/what did you expect to happen?
When trying to download arifact with /artifact-files endpoint of argo-server with invalid UID, then argo-server panics.
Panic log:
2024/01/18 09:01:21 http: panic serving 10.176.0.2:38940: runtime error: invalid memory address or nil pointer dereference
goroutine 77260 [running]:
net/http.(*conn).serve.func1()
/usr/local/go/src/net/http/server.go:1868 +0xb9
panic({0x26b9ba0?, 0x50e4480?})
/usr/local/go/src/runtime/panic.go:920 +0x270
# ------ split for readability ------ #
github.com/argoproj/argo-workflows/v3/server/artifacts.(*ArtifactServer).GetArtifactFile(0xc0008b3c20, {0x3a70670, 0xc0008f42c0}, 0xc01f058100)
/go/src/github.com/argoproj/argo-workflows/server/artifacts/artifact_server.go:134 +0x898
# ------ split for readability ------ #
net/http.HandlerFunc.ServeHTTP(0xc000b00000?, {0x3a70670?, 0xc0008f42c0?}, 0xc02b4118a0?)
/usr/local/go/src/net/http/server.go:2136 +0x29
net/http.(*ServeMux).ServeHTTP(0x9721f20?, {0x3a70670, 0xc0008f42c0}, 0xc01f058100)
/usr/local/go/src/net/http/server.go:2514 +0x142
github.com/argoproj/argo-workflows/v3/server/apiserver.(*argoServer).newHTTPServer.Interceptor.func5({0x3a6a8e0?, 0xc01e1369a0}, 0xc01f058100)
/go/src/github.com/argoproj/argo-workflows/server/apiserver/accesslog/interceptor.go:20 +0xcf
net/http.HandlerFunc.ServeHTTP(0x106eb40a?, {0x3a6a8e0?, 0xc01e1369a0?}, 0xc0000583c0?)
/usr/local/go/src/net/http/server.go:2136 +0x29
github.com/argoproj/argo-workflows/v3/server/apiserver.(*argoServer).newHTTPServer.(*Middleware).Handle.func6({0x3a6a8e0, 0xc01e1369a0}, 0x0?)
/go/pkg/mod/github.com/sethvargo/go-limiter@v0.7.2/httplimit/middleware.go:125 +0x1d6
net/http.HandlerFunc.ServeHTTP(0x515a940?, {0x3a6a8e0?, 0xc01e1369a0?}, 0xc02b411b50?)
/usr/local/go/src/net/http/server.go:2136 +0x29
net/http.serverHandler.ServeHTTP({0xc013194120?}, {0x3a6a8e0?, 0xc01e1369a0?}, 0x6?)
/usr/local/go/src/net/http/server.go:2938 +0x8e
net/http.(*conn).serve(0xc0131b0000, {0x3a7f6c8, 0xc000829f80})
/usr/local/go/src/net/http/server.go:2009 +0x5f4
created by net/http.(*Server).Serve in goroutine 145
/usr/local/go/src/net/http/server.go:3086 +0x5cb
Version
3.5.4
Paste a small workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflows that uses private images.
n/aLogs from the workflow controller
n/a
Logs from in your workflow's wait container
n/a