Description

There have been quite a few changes to how we handle responses. The cache daemon will now truncate any response that returns more than 250 items. They will also now return a incomplete response to indicate that the response was truncated as well as a refresh_status to indicate if they're still building the cache in the background. The latter will also be used eventually when partial results are returned.

These two new fields are independent which means for example we could have an incomplete response and still be refreshing in the background or a complete response and still be refreshing in the background.

I've also made a change to always show the filters so the user has access to the refresh button. This is mainly needed as we will eventually return partial responses and for users to refresh while waiting for the cache to build. Previously we had no way for letting users to refresh without using the electron refresh hot keys.

The dynamic scope filters for targets now just returns all the scopes the user have access to instead of ones just associated with targets. Foundations added implicit-scopes which are all scopes associated with targets/sessions but we would have to duplicate the scope models to be able to use it (otherwise all scope calls would go through the daemon) so I ended up just loading all scopes. It might be better to just wait until scopes are part of the daemon as it's just an extra call right now that likely won't change much for the filters.

Example response from cache daemon with over 250 results:

{
  "status_code": 200,
  "item": {
    "targets": [
      {
        "id": "ttcp_01un6InYFN",
        "scope_id": "p_t9Wd9rDQgW",
        "scope": {
          "id": "p_t9Wd9rDQgW",
          "type": "project",
          "name": "project0",
          "description": "Test project scope #0",
          "parent_scope_id": "o_a0XERM5apw"
        },
        "name": "Test TCP Target #141984",
        "created_time": "2024-08-28T20:42:25.194206Z",
        "updated_time": "2024-08-28T20:42:28.553402Z",
        "version": 3,
        "type": "tcp",
        "session_max_seconds": 2147483647,
        "session_connection_limit": -1,
        "attributes": {
          "default_port": 22
        },
        "authorized_actions": [
          "remove-credential-sources",
          "authorize-session",
          "update",
          "remove-host-sources",
          "delete",
          "add-credential-sources",
          "no-op",
          "read",
          "set-credential-sources",
          "add-host-sources",
          "set-host-sources"
        ]
      }
    ],
    "incomplete": true,
    "refresh_status": "not-refreshing"
  }
}

Screenshots (if appropriate)

How to Test

Build from the llb-cache-speedup branch in boundary and copy it to the desktop CLI folder. Use a cluster that has a decent amount of targets. My HCP cluster has ~50k targets if you'd like to try with that. If you want 500k+ targets you'll need to use the boundary scale repo. I can also whitelist your IP if you want to use my cluster.

Checklist

[x] I have added before and after screenshots for UI changes
[x] I have added JSON response output for API changes
~[ ] I have added steps to reproduce and test for bug fixes in the description~
[x] I have commented on my code, particularly in hard-to-understand areas
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works

Name	Status	Preview	Comments	Updated (UTC)
boundary-ui	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 6, 2024 4:33pm
boundary-ui-desktop	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 6, 2024 4:33pm

hashicorp / boundary-ui

Use updated cache daemon #2475

Description

Screenshots (if appropriate)

How to Test

Checklist