Bug
DevCycleLocalClient leaks native linear memory on every variableValue() call. The JVM heap stays flat while process RSS climbs ~370 bytes per evaluation, so any service doing a steady volume of evaluations eventually gets OOM-killed. We hit this regularly in production (a worker service that evaluates ~30 flags per minute).
Reproduction
Claude helped me author a pretty minimalist reproduction of this. You'll need Docker and an API key. https://github.com/robbiebowman-rf/devcycle-leak-mre
Instructions are in the repo's README.
The repro takes about 2 minutes and has some logging showing RSS space climbs while the heap stays flat.
Suspected cause
Every evaluation copies the user into the WASM bucketing module's memory to run the lookup. Normally that scratch memory should be released afterwards, but on the protobuf variable path it never is, so each call leaves a bit behind. WASM memory can only grow and never shrinks, so those leftovers pile up until the process runs out.
Looking at the decompiled LocalBucketing, getVariableForUserProtobuf allocates via newUint8ArrayParameter but never calls unpinAll() (or otherwise frees/collects), whereas other methods like generateBucketedConfig do call unpinAll(). That missing cleanup looks like the leak.
Bug
DevCycleLocalClientleaks native linear memory on everyvariableValue()call. The JVM heap stays flat while process RSS climbs ~370 bytes per evaluation, so any service doing a steady volume of evaluations eventually gets OOM-killed. We hit this regularly in production (a worker service that evaluates ~30 flags per minute).Reproduction
Claude helped me author a pretty minimalist reproduction of this. You'll need Docker and an API key. https://github.com/robbiebowman-rf/devcycle-leak-mre
Instructions are in the repo's README.
The repro takes about 2 minutes and has some logging showing RSS space climbs while the heap stays flat.
Suspected cause
Every evaluation copies the user into the WASM bucketing module's memory to run the lookup. Normally that scratch memory should be released afterwards, but on the protobuf variable path it never is, so each call leaves a bit behind. WASM memory can only grow and never shrinks, so those leftovers pile up until the process runs out.
Looking at the decompiled
LocalBucketing,getVariableForUserProtobufallocates vianewUint8ArrayParameterbut never callsunpinAll()(or otherwise frees/collects), whereas other methods likegenerateBucketedConfigdo callunpinAll(). That missing cleanup looks like the leak.