Async build goroutine captures released gin.Context (potential race/panic)

[RazorSh4rk]

Bug Description

In route-handlers/codehandlers.go:72-79, the async goroutine started after POST /function/upload captures c *gin.Context and calls c.FormFile() and c.SaveUploadedFile() after the HTTP response has already been sent. Gin contexts are not safe for use after the handler returns — the request body and multipart form may be cleaned up.

Steps to Reproduce

1. Upload a function via POST /function/upload
2. The handler returns 200 {"message": "Code uploaded, build process started"} immediately
3. The goroutine then tries c.FormFile("file") and c.SaveUploadedFile(...) with the now-released context
4. This can cause silent failures, truncated file saves, or panics

Root Cause

go func() {
    zipFile, _ := c.FormFile("file")    // c is released!
    id := uuid.New().String()
    cacheDir := fmt.Sprintf("./buildcache/%s/", id)
    fPath := fmt.Sprintf("%s%s", cacheDir, zipFile.Filename)
    c.SaveUploadedFile(zipFile, fPath)   // c is released!
    // ...
}()

Suggested Fix

Save the uploaded file BEFORE spawning the goroutine, then pass the file path to the goroutine:

zipFile, err := c.FormFile("file")
if err != nil {
    c.JSON(400, gin.H{"error": err.Error()})
    return
}
cacheDir := fmt.Sprintf("./buildcache/%s/", uuid.New().String())
fPath := fmt.Sprintf("%s%s", cacheDir, zipFile.Filename)
c.SaveUploadedFile(zipFile, fPath)

c.JSON(200, gin.H{"message": "Code uploaded, build process started", "data": lambda})

go func() {
    // work with fPath and cacheDir, NOT c
    // ...
}()

Environment

• Lambda@Home v0.0.2