Websocket closing on backend on empty apply

[andrewcopley]

When applying an empty namespace, it closes the websocket when you go back to the catalog. (we believe it is the unsubscribe)

Error log is as follows from minikube dashboard backend logs:
time="2019-01-24T22:35:36Z" level=error msg="exec error" err="exit status 1" kubectl args="[apply -f /tmp/yipee-kubectl-094427935.yml]" stderr="error: no objects passed to apply\n" tempfile data=
time="2019-01-24T22:36:02Z" level=debug msg="closing statusChan for closed websocket"
time="2019-01-24T22:36:02Z" level=debug msg="statusWriter terminating"
2019/01/24 22:36:02 http: panic serving 172.17.0.1:64549: interface conversion: interface {} is nil, not string
goroutine 76671 [running]:
net/http.(*conn).serve.func1(0xc0001903c0)
    /usr/local/go/src/net/http/server.go:1746 +0xd0
panic(0x8a9d20, 0xc0004ed890)
    /usr/local/go/src/runtime/panic.go:513 +0x1b9
main.websocketHandler(0x9a8b60, 0xc00051e0e0, 0xc00015fa00)
    /usr/src/goapi.elf/status.go:488 +0xc99
net/http.HandlerFunc.ServeHTTP(0x9411a8, 0x9a8b60, 0xc00051e0e0, 0xc00015fa00)
    /usr/local/go/src/net/http/server.go:1964 +0x44
github.com/gorilla/mux.(*Router).ServeHTTP(0xc00010e310, 0x9a8b60, 0xc00051e0e0, 0xc00015fa00)
    /go/pkg/mod/github.com/gorilla/mux@v1.6.2/mux.go:162 +0xf1
net/http.serverHandler.ServeHTTP(0xc00006d380, 0x9a8b60, 0xc00051e0e0, 0xc00015f800)
    /usr/local/go/src/net/http/server.go:2741 +0xab
net/http.(*conn).serve(0xc0001903c0, 0x9a9420, 0xc0004d7200)
    /usr/local/go/src/net/http/server.go:1847 +0x646
created by net/http.(*Server).Serve
    /usr/local/go/src/net/http/server.go:2851 +0x2f5
time="2019-01-24T22:36:03Z" level=debug msg="created websocket connection"
time="2019-01-24T22:36:03Z" level=debug msg="websocket statusWriter running"

[jd3quist]

This doesn't have anything to do with the empty apply. Reproduce the problem by (after the websocket is created) just choose "New" from the catalog. When you exit the editor, the UI sends this unsubscribe on the websocket:

{"msg":"unsubscribe"}

A valid unsubscribe looks like this:

{"msg":"unsubscribe","namespace":"yipee"}

Of course we could make the backend more resilient to bad input on the websocket instead of crashing/restarting. For now, we're counting on the UI to be precise and correct about the format of messages across the websocket though

[andrewcopley]

Fixed on front end. There is no update status on the controllers in the canvas still, but we are now sending the correct unsubscribe and subscribing correctly on new.