Skip to content

only one app in "coder_app" resource block using "for_each" is considered #6234

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
nlbkoll opened this issue Feb 16, 2023 · 7 comments · Fixed by #6242
Closed

only one app in "coder_app" resource block using "for_each" is considered #6234

nlbkoll opened this issue Feb 16, 2023 · 7 comments · Fixed by #6242
Assignees

Comments

@nlbkoll
Copy link

nlbkoll commented Feb 16, 2023

We want to create coder apps dynamically through the following terraform resource block:

resource "coder_app" "apps" {
  for_each = local.apps_map
  ...
}

If local.apps_map contains more than one entry, only one of them is considered by coder and appears as button in the UI.

As an example, we used the following coder.yaml to populate local.apps_map:

coder:
  apps:
    - display_name: file-server-8080
      slug: file-server-8080
      icon: /icon/code.svg
      url: http://localhost:8080
      subdomain: false
      share: public
      healthcheck:
        url: http://localhost:8080
        interval: 3
        threshold: 10
    - display_name: file-server-8081
      slug: file-server-8081
      icon: /icon/code.svg
      url: http://localhost:8081
      subdomain: false
      share: public
      healthcheck:
        url: http://localhost:8081
        interval: 3
        threshold: 10

Relevant excerpt of the workspace creation logs:

Terraform 1.3.4
coder_agent.main: Plan to create
coder_app.apps["file-server-8080"]: Plan to create
coder_app.apps["file-server-8081"]: Plan to create
coder_agent.main: Creating...
coder_agent.main: Creation complete after 0s [id=94d4ea2f-9dca-4dde-8e34-d787f246f9ee]
coder_app.apps["file-server-8080"]: Creating...
coder_app.apps["file-server-8081"]: Creating...
coder_app.apps["file-server-8081"]: Creation complete after 0s [id=dff03841-75cc-43e4-8ac5-cdfd48fa652e]
coder_app.apps["file-server-8080"]: Creation complete after 0s [id=0108665e-b7c4-4076-b59b-f3fe37b91839]
Apply complete! Resources: 10 added, 0 changed, 0 destroyed.
Outputs: 0

After creating a workspace we proved the mentioned misbehaving by running

$ curl -sk https://<url>/api/v2/workspaceagents/me/metadata?coder_session_token=<token> | jq .
{
  "git_auth_configs": 1,
  "vscode_port_proxy_uri": "https://<url>",
  "apps": [
    {
      "id": "<id>",
      "url": "http://localhost:8081",
      "external": false,
      "slug": "file-server-8081",
      "display_name": "file-server-8081",
      "icon": "/icon/code.svg",
      "subdomain": false,
      "sharing_level": "public",
      "healthcheck": {
        "url": "http://localhost:8081",
        "interval": 3,
        "threshold": 10
      },
      "health": "unhealthy"
    }
  ],

Only the apps within the above response body are considered in the UI and health check loop, so the bug must appear earlier.

We eventually nailed it down to these two lines. Here, the label for a coder_app resource block constructed through for_each is the same for all contained applications, which is not suitable to be used as a key in a map, since each app entry is overwritten by its successor.

@kylecarbs
Copy link
Member

Ahh, will fix!

@kylecarbs
Copy link
Member

A fix is on the way in the attached PR. Thanks for looking through the code too, you were indeed correct where the problem was!

@MrPeacockNLB
Copy link
Contributor

Thanks in advance for fixing this! Yeah this took some time until we understood what is wrong here.

@kylecarbs
Copy link
Member

It was a silly assumption on our part that was just straight-up wrong, so I'm happy y'all found it! Would you like me to do a patch with this in it today? Happy to do so if it'd help y'all out.

@MrPeacockNLB
Copy link
Contributor

no thanks. we can wait until next release. You release so often we can wait for sure

@mtojek mtojek reopened this Feb 17, 2023
@mtojek
Copy link
Member

mtojek commented Feb 17, 2023

Reopening the issue as we spotted a blocker.

Reverting now: #6248

@kylecarbs
Copy link
Member

Fixed again in #6255

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants