Complete service names in shell completions - #254
Conversation
| } | ||
|
|
||
| return completeServiceIDs(cmd, app, toComplete) | ||
| services, err := listServices(cmd, app) |
There was a problem hiding this comment.
Am I right that essentially every time you press tab to complete in the shell, a new tiger process is spawned to run this code, and this hits the api to fetch all services?
Not really something to address now, but this is probably a good place to add a cache in the future. No idea how many services a customer might have, and if this would ever be noticeably laggy.
There was a problem hiding this comment.
Yes, when you press tab for a given prefix, it spawns tiger and runs this custom completion handler, which hits the API to fetch and return the results. However, subsequent tab presses for the same prefix (to cycle through the results) do not hit the API until/unless you enter more characters, so they tend to be very fast.
There can be a noticeable delay for that first tab press, though in my experience, it's usually not significant. The endpoint for listing services usually returns in under 100ms.
I am fairly hesitant to add a cache, given the complexity of trying to keep the cache in-sync, and the downside of having completion ever not work correctly if a service was just recently created or deleted.
There was a problem hiding this comment.
Right, I really mean if we ever find that the requests consistent take more than a few hundred ms for some people, we should probably do something. I was thinking a very short TTL cache, just so that if you are trying to find/complete something, back-to-back tabs wouldn't be so frustrating.
Perhaps better than a cache would be to send toComplete to the backend and do the filter in the SQL query.
There was a problem hiding this comment.
Agreed. There's also the fact that we're using the normal service list endpoint, which fetches and returns a lot more information than just the service names/IDs (which is all we really need for the sake of completions). We could consider making an internal service list endpoint that was stripped down and only returned the bare minimum service info, which would also probably help.
2 participants
#241 made commands accept a service name anywhere they accept an ID, but shell completion still offered only IDs. Completion for a service argument now offers each service by name, falling back to its ID when what's typed matches the ID instead. The
--service-idflag still completes only IDs, since that's all the flag accepts.