filter does not work when switching from pod to ingress view

[mosheavni]

Describe the bug
ok this is weird, I started experiencing it a while ago but disregarded it.
now it's bugging me
when opening straight to pods view, then applying a filter, then switching to ingress, even though there are resources that should match the filter, I see 0 ingresses!
I ran a git bisect and found that this: b637e87 is the first bad commit:

b637e870ba5942697314afa1aa65547a3ba35e95 is the first bad commit

which makes this the last good commit: a076125

a07612541e5b4fe05f5309460def2e1a0ced5f75

Bad commit reproduction

1. make sure we're aligned to origin/maon
2. open k8s on pods view
3. filter for a value
4. switch to ingress view
5. filter is applied, ingress exists, yet I see 0!
   

Good commit reproduction

1. reset to this commit:

git checkout a07612541e5b4fe05f5309460def2e1a0ced5f75

2. open k8s on pods view
3. filter for a value
4. switch to ingress view
5. filter is applied, ingress exists, i see the ingress

Expected behavior

Screenshots

Environment (please complete the following information):

• OS: [e.g. OSX]
• Neovim version [e.g. 0.10]

Additional context

[Ramilito]

This is super weird, that commit isn't even touching the code relevant to the filter.
I'm not able to reproduce even though I see it happening in the gif!

Could it be something with the state files? Could you check if it looks ok?

[mosheavni]

This is super weird, that commit isn't even touching the code relevant to the filter. I'm not able to reproduce even though I see it happening in the gif!

Could it be something with the state files? Could you check if it looks ok?

checked and state file looks fine. i doubled that and removed the state file completely, but the issue stills seem to happen

[mosheavni]

this is bad. I have to close and reopen hundred times a day..

[Ramilito]

oh man, that's not acceptable, so hard to debug something I can't recreate.
I'll try more tonight, the overview is ready to be checked in, not completed but it gives us something to build on at least. After that, I'll try to fix this.

[mosheavni]

Owner

i appreciate it.

[Ramilito]

I could not for the life of me replicate that behaviour, found your dotfiles and tried with that setup as well but still nothing.
I'm guessing there is something with the fallback view, will try to look at it again but for now I've added an ingress view, could you check if that fixes it?

[mosheavni]

that definitely looks better now, thanks! problem is, I experience it with every fallback resource, so yes it looks like the problem is on the fallback view somehow. maybe we're not clearing stuff when changing a fallbackview? unlike any other view, fallback can be for multiple resources so a proper cleanup is in order?

[Ramilito]

yeah something seems to be off there, just not sure why I can't replicate it.
Did a guess fix in d798b5a and merged to main, but not sure if it solves it, could you test it out?

[mosheavni]

doesn't seem to solve it.
I'm trying to debug it for the last hour, it seems that the problem lies within find.is_in_table

[mosheavni]

for some reason this prevents the problem from happening:
#319

[Ramilito]

I love it, mystery programming 😅