Delete/re-deploy uses function DB key (UUID) as Docker container ID

[RazorSh4rk]

Bug Description

In route-handlers/codehandlers.go:64-65, the teardown path uses docker.Kill(existing.ID) where existing.ID is the Badger DB key (a UUID like 8e79b050-...), NOT a Docker container ID. This always fails because Docker has no container with that ID.

Combined with the log.Fatal bug in kill.go, this crashes the server on every delete or re-deploy attempt.

Steps to Reproduce

1. Deploy a function
2. Try to delete it or re-deploy with the same name
3. Server crashes

Root Cause

codehandlers.go:59-70:

if key, existing, found := findFunctionByName(db, lambda.Name); found {
    docker, err := newDockerClient()
    if err != nil {
        log.Println(err)
    } else {
        docker.Kill(existing.ID)        // existing.ID is Badger UUID, NOT Docker container ID!
        docker.RemoveContainer(existing.ID)
        docker.RemoveImage(existing.Tag)
        docker.Close()
    }
    db.Delete(key)
}

The ID field on LambdaFun is set in the async goroutine (line 125: lambda.ID = containerId), but if the build failed or L@H restarted before the goroutine completed, it still holds the DB key not a Docker ID. The delete path should look up the running container by function name/tag, not by the stored ID field.

Environment

• Lambda@Home v0.0.2