kubectl resources completions don't work when using a namespace in the command.

[jonwraymond]

Discord username (optional)

No response

Describe the bug

When using the -n or --namespace option it list the namespace just fine for auto-completion of the namespace, however, it doesn't list namespaced nested resources such as pods when targeting a namespace in the kubectl command. If I swap context to the namespace it works fine for resources without the --namespace or -n flag.

To reproduce

kubectl get pods -n kube-system <doesn't auto-complete resources>

Expected behavior

No response

Screenshots

No response

Operating system

MacOS

Operating system and version

Ventura 13.2.1

Shell Version

zsh 5.8.1 (x86_64-apple-darwin22.0)

Current Warp version

v0.2023.11.28.08.02.stable_00

Regression

Yes, this bug started recently or with an X Warp version

Recent working Warp date

No response

Additional context

No response

Does this block you from using Warp daily?

Yes, this issue prevents me from using Warp daily.

Is this a Warp specific issue? (i.e. does it happen in Terminal, iTerm, Kitty, etc.)

Yes, this I confirmed this only happens in Warp, not other terminals.

Warp Internal (ignore): linear-label:b8107fdf-ba31-488d-b103-d271c89cac3e

None

[dannyneira]

Hi @jonwraymond Thanks for letting us know. I was able to reproduce this issue on my end. As a workaround, I recommend you change the order of the pods keyword to after the namespace, so for example kubectl get -n kube-system pods , then the pods completions should work for that specific namespace, hope this helps!

CleanShot.2023-12-04.at.16.40.51.mp4

Please let me know if this helps with your issue. To anyone else facing this issue, please add a :+1: to the original post at the top or comment with your details, and subscribe if you'd like to be notified.

[jonwraymond]

The workaround works. Thank you!

[lilHermit]

It seems the autocomplete is very dependent on the order of namespace and context flags. Is there anyway this can be improved as it works well with kitty and zsh. I always use the context followed by the namespace as it's safer to do so. For example kubectl --context staging-cluster -n project1 get pods This way I can up arrow and change a few parameters safe in the knowledge I'm still operating on the staging-cluster and project namespace

[cdenneen]

@dannyneira I'm following your video but when I type kubectl -n I don't get a list of namespaces.
When I type kubectl -n flux-system get po don't get a list of pods... tab gives me list of switches and local files but no pods or namespaces.

Using: v0.2024.04.30.08.02.stable_01

[dannyneira]

@cdenneen the order of the command does have an impact on the completions it seems that is part of the bug.

kubectl -n flux-system get pods doesn't work, while kubectl get -n flux-system pods should, so putting the get after the -n namespace instead of before seems to have an effect.

I've let the team know about this and we'll post updates on this thread.

[cdenneen]

@dannyneira it still isn't working
kubectl get -n doesn't provide list of namespaces
kubectl get -n flux-system po doesn't provide list of pods

[dannyneira]

Heard, sorry about this. I'll check with the team for any updates. As a possible workaround, you can run your preferred shell (zsh,bash,fish) as a subshell, then Warp will fall back to shell-based completions. Warp features like blocks will temporarily not work, but the completions should be as you expect in a traditional terminal.

[lentzi90]

This seems to be partially fixed in v0.2024.10.29.08.02.stable_02. I do get proper completion with namespace in the command for the default kubeconfig and context. However, if I override it with export KUBECONFIG=another-kubeconfig.yaml warp will still suggest resources from the default ~/.kube/config. 🤦

[lucieleblanc]

This issue has been investigated and fixes have been submitted:

Root Cause: Two bugs in the completion engine's subcommand navigation in warp-internal:

1. Loose option matching: signature_from_tokens used s.contains(token) to match tokens against option names, which caused false positives. For example, --no-headers contains -n as a substring, so typing -n (meaning --namespace) would incorrectly match --no-headers (a switch with no arguments). This prevented the parser from skipping the namespace value token, breaking subcommand navigation.

2. V2 lookup missing flag-skipping: deepest_matching_subcommand_signature would stop searching for subcommands at the first non-subcommand token. For kubectl -n kube-system get pods, it would encounter -n and return the root kubectl signature, never reaching the get subcommand.

Fixes:

• warp-internal: https://github.com/warpdotdev/warp-internal/pull/24138
• command-signatures (generator tests): Add kubectl namespace flag generator tests (APP-3476) command-signatures#255

Note: The kubectl generators in command-signatures already correctly forward --namespace from any position in the token list. The fix is entirely in the completion engine's subcommand lookup logic.