[0.6.0] Invalid memory address or nil pointer dereference on diff and sync

[miguel-martinez-tfs]

Hi, I've recently upgraded to version 0.6.0 from 0.5.2. I've successfully dumped workspace yaml files with the --with-id flag

deck dump --all-workspaces --with-id --kong-addr=value

and tried to execute a diff command with one of the dumped files on my local instance

deck diff -s default.yaml

but the following error appears:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x14fefec]

goroutine 5 [running]:
github.com/hbagdi/deck/cmd.checkWorkspace(0x162c976, 0x15, 0xc0003cc498, 0x7, 0x1ababd8, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
        /home/hbagdi/deck/cmd/common.go:45 +0x18c
github.com/hbagdi/deck/cmd.syncMain(0x7ffeefbff9b5, 0x1a, 0xc0001cbd01, 0xa, 0x0, 0x0)
        /home/hbagdi/deck/cmd/common.go:64 +0xbf
github.com/hbagdi/deck/cmd.glob..func1(0x1a95460, 0xc00000c0c0, 0x0, 0x2, 0x0, 0x0)
        /home/hbagdi/deck/cmd/diff.go:26 +0x4a
github.com/spf13/cobra.(*Command).execute(0x1a95460, 0xc00000c080, 0x2, 0x2, 0x1a95460, 0xc00000c080)
        /home/hbagdi/go/pkg/mod/github.com/spf13/cobra@v0.0.3/command.go:762 +0x460
github.com/spf13/cobra.(*Command).ExecuteC(0x1a94ae0, 0x0, 0x0, 0x0)
        /home/hbagdi/go/pkg/mod/github.com/spf13/cobra@v0.0.3/command.go:852 +0x2ea
github.com/spf13/cobra.(*Command).Execute(...)
        /home/hbagdi/go/pkg/mod/github.com/spf13/cobra@v0.0.3/command.go:800
github.com/hbagdi/deck/cmd.Execute.func2(0xc00005e010, 0xc000022070)
        /home/hbagdi/deck/cmd/root.go:59 +0x2d
created by github.com/hbagdi/deck/cmd.Execute
        /home/hbagdi/deck/cmd/root.go:58 +0xba

How can I resolve this?

[hbagdi]

This is a bug on decK's end. Will be fixed with v0.6.1.

However, I'm curious how you got to hit that bug. Was the kong-addr value correctly formed?

[miguel-martinez-tfs]

The kong-addr was correctly formed. I've found the cause of the issue; it was a problem on my end. The Kong docker instance on my local machine was not running. However, after starting it, I now received a different error:

Error: workspace 'default' does not exist in Kong, please create it before running decK.

Which is strange because the default workspace should be the one that always exists. A GET to the localhost:8001/workspaces endpoint returns the following:

{
    "next": null,
    "data": [
        {
            "comment": null,
            "created_at": 1570559532,
            "config": {
                "portal_access_request_email": null,
                "portal_developer_meta_fields": "[{\"title\":\"full_name\",\"label\":\"Full Name\",\"is_email\":false,\"validator\":{\"type\":\"string\",\"required\":true}}]",
                "portal_auto_approve": null,
                "portal_cors_origins": null,
                "portal_reset_success_email": null,
                "portal": true,
                "portal_emails_reply_to": null,
                "portal_token_exp": null,
                "portal_auth_conf": null,
                "portal_emails_from": null,
                "portal_reset_email": null,
                "portal_approved_email": null,
                "portal_invite_email": null,
                "meta": null,
                "portal_auth": ""
            },
            "id": "43885560-1026-4d4f-b24d-000da97f8408",
            "name": "default",
            "meta": {
                "color": null,
                "thumbnail": null
            }
        }
    ]
}

[hbagdi]

Yes, that's because you are running into #94.

So we have two bugs:

• Deck 0.6.0 error retrieve workspace during sync action #94
• decK panics when there is an error making the request to verify the workspace.

I'll be fixing these this week.
Meanwhile, you can adopt the following workaround:

You can remove _workspace from your YAML file, and simply apply the file. That way, you will not hit these bugs.

[miguel-martinez-tfs]

Ok, I'll apply the workaround and let you know if I encounter any more problems. Thanks for the help.