NVIDIA/nvcf

Describe the bug Manager.initializePlugins (manager.go#L110) sets accountName = "" when it reaches the nkey plugin. accountName is the outer loop variable for the account, not a per-plugin copy, so every plugin listed after nkey on that account is registered under account "" instead of its real account. Steps or code to reproduce bug Config: account_configs: APP: enabled_plugins: - id: nkey - id: sis alias: oidc A client authenticating with {"account":"APP","pluginName":"oidc", ...} gets 404 plugin oidc not found for account APP. A copy of the loop registers keys {"", nkey} and {"", oidc}. Expected behavior oidc is registered under APP regardless of where nkey appears in the list. Additional context The chart's default config lists sis before nkey, so stock installs work; any config that lists nkey first breaks the plugins after it. There is no manager test today. Suggested fix: key := accountName; if plugin.ID == "nkey" { key = "" } and a test with nkey liste

Describe the bug DistributedLockGuard::drop (distributed_lock.rs#L135) releases the lock with DELETE FROM locks WHERE lock_name = ? (statements.rs#L26) and no IF node_id = ?. If the holder ran past the lock TTL, another node may already own the lock; the late drop deletes that node's row, a third node can then acquire it, and multiple nodes process the same bucket concurrently. Both guard users can outlive the TTL: The NVCF API bucket loop (nvcf_client.rs) checks its 15 s budget only before each request, so the final request can run past it. The scaling loop (work/mod.rs) holds a 120 s lock while draining every function in the bucket, with no refresh. The row is also written with an LWT (INSERT ... IF NOT EXISTS) and deleted with a plain write; Cassandra does not order non-LWT writes against Paxos writes on the same partition. Steps or code to reproduce bug Run two autoscaler nodes. Make processing of one bucket take longer than its lock TTL (e.g. slow NVCF API responses). Node B ac

Describe the bug A stickiness threshold of 12 minutes or more can never be met, so scaling in that direction is disabled with no error. The API accepts stickiness windows up to one hour (AutoscalingConfigurationDto: size <= 1h, threshold < size). The autoscaler fetches utilization over lookback (default 600 s, scaling/mod.rs#L34) at a 60 s step (work/mod.rs#L89), which yields at most 11 samples. breached_enough takes the last window_minutes samples and requires required_minutes of them to breach; with fewer samples than the window it counts what is there, so required_minutes > 11 is unreachable, and a 30-minute window is judged on ~10 minutes of data. Steps or code to reproduce bug Deploy a function with scale-up stickiness size: 30m, threshold: 15m. Hold utilization at 100% for 40 minutes. Watch the autoscaler debug log. Expected behavior Scale-up after 15 breached minutes. Observed: scale-up gate: 11 of 11 recent sample(s) breached (need 15, window 30) every cycle and no scale-up.

Describe the bug The self-managed stack publishes POST /v1/admin/keys on the shared gateway with no authentication in front of it. Anyone who can reach api-keys.<domain> can mint an admin-scoped NVCF JWT. The proxy checks only the HTTP method before signing (handlers.Keys). Its README and SECURITY.md both state the gateway must authenticate callers, and SECURITY.md lists unauthorized minting as threat 1. deploy/stacks/self-managed/global.yaml.gotmpl hard-codes adminIssuerProxy.gateway.enabled: true on the shared gateway, and the chart's httproute.yaml creates a plain HTTPRoute with no SecurityPolicy or auth filter. The 1.0.1 gateway-routing doc shows calling it through a public AWS ELB hostname. Steps or code to reproduce bug Install the self-managed stack with default values. From any host that can reach the shared gateway, run curl -X POST https://api-keys.<domain>/v1/admin/keys with no credentials. Expected behavior The request is rejected unless the caller is authenticated and

Describe the bug Store.Get in ratelimiter/olric_store.go increments a counter by reading it with dmap.Get, adding 1 in process, and writing it back with dmap.Put. The read and write are not atomic, so two concurrent checks that read the same value both write N+1 and one request is never counted. The service runs multiple replicas against one embedded Olric cluster, and HTTP invocation / grpc-proxy fire checks asynchronously, so concurrent checks on a hot function version are the normal case. Under load the limiter admits more than the configured rate, and the excess grows with replica count and concurrency. Steps or code to reproduce bug Run the ratelimiter with 2 replicas. Configure a function version with rateLimit: 10-S. Send ~200 concurrent RateLimit RPCs for that function version within one second, spread across both replicas. Count ALLOW results. Expected behavior At most 10 ALLOW results per second. Observed: more than 10, because increments are lost. Additional context The L