You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 1, 2022. It is now read-only.
c.loggedAllowedNS[name] =false// reset, so if the namespace goes away we'll log it again
It seems that concurrent goroutines are calling the getAllowedAndExistingNamespaces function on the same cluster object, and this results in a panic as they write to the same key on the same map.
This should pretty easily fixable via a RWLock or a map of RWLocks, and moving the map writes & reads into Cluster helper functions or a sync map: https://golang.org/pkg/sync/#Map
To Reproduce
Unknown, it's just started to happen, though this is likely only reproducable when allowed-namespaces is provided
Expected behavior
No panics
Logs
Logs included in the description
Additional context
Flux version: 1.17.1
Kubernetes version:
Git provider:
Container registry provider:
The text was updated successfully, but these errors were encountered:
Describe the bug
As of version 1.17.1, seeing occasional panics in flux with the following trace of the panicking function
This points to this line:
flux/pkg/cluster/kubernetes/kubernetes.go
Line 314 in 0d3f1d3
It seems that concurrent goroutines are calling the getAllowedAndExistingNamespaces function on the same cluster object, and this results in a panic as they write to the same key on the same map.
This should pretty easily fixable via a RWLock or a map of RWLocks, and moving the map writes & reads into Cluster helper functions or a sync map: https://golang.org/pkg/sync/#Map
To Reproduce
Unknown, it's just started to happen, though this is likely only reproducable when allowed-namespaces is provided
Expected behavior
No panics
Logs
Logs included in the description
Additional context
The text was updated successfully, but these errors were encountered: