fix(data-store): plug the FFI leak, NUL-terminate the Go get result, skip empty syncs

[vaidehi-figma]

Three fixes on the data-store path. All present on upstream main too - statsig-ffi/src/data_store_c.rs has not been touched since 2025-10-15.

1. The Set args were leaked (the reason for this PR)

string_to_c_char is CString::new(s).into_raw(), which transfers ownership to the callback. statsig-dotnet reclaims it in the finally block of GetNative, SetNative and SupportPollingNative. statsig-go never did, so all three callback args leaked on every call.

Set is the one that hurts: args_json is the full serialized specs - ~18MB for our project - and with a data store configured SpecStore writes on the sync timer, every 10-20s in our staging logs. That is 54-108MB/min of unreclaimable native memory for the process lifetime.

It matches what we measured in production: ~45MB/min of RSS growth per pod, sawtoothing into whatever cgroup limit was set and OOMKilling every ~20 minutes. Go live heap stayed flat at ~100MiB against 680MB RSS, so ~85% was native and invisible to the Go profiler. It began the day a data store was first configured, and Set only runs when one is.

Fixed with a deferred free_string in each of the three Go callbacks, matching statsig-dotnet. free_string was already bound in statsig_ffi.go, so nothing new is exported.

An earlier revision of this PR freed in DataStoreC instead. Cursor correctly flagged that as a double-free against statsig-dotnet, which already frees the same pointer - thanks. Reverted; the callback owns the args, and Go is the binding that needed fixing.

2. The Go get callback returned an unterminated, possibly empty buffer

result := []byte(store.functions.Get(*keyStr))
return &result[0]

Rust reads this back with CStr::from_ptr. Two problems, both fixed by appending one 0 byte:

• No terminator - from_ptr runs past the end of the slice until it happens to find a zero. It survives today only because Go zeroes large fresh allocations.
• Panics on empty - &result[0] on a zero-length slice, inside a purego callback. An adapter cannot signal "no data", even though the Rust side already handles that: a nil DataStoreResponse.result becomes DataStoreFailure and falls back to the network adapter.

3. Background sync forwarded empty updates

start() rejects a nil result with DataStoreFailure, letting StatsigCustomizedSpecsAdapter fall through to the network adapter. execute_background_sync_impl has no equivalent check, so a nil flows into send_specs_update_to_listener, where unwrap_or_default() makes it an empty body that set_values can only fail to deserialize - once per tick, for as long as the store has nothing to serve.

Nothing is corrupted: the failure happens during Prep, before the write lock, so loaded specs survive. But the sync is pure noise. Now it bails on a nil result and says so, matching start().

Testing

labmate's RSS should stop climbing and flatten near its ~360MB working set instead of sawtoothing to the cgroup limit.

After merging

Tag statsig-go/v0.19.4-figma2 - the figma-release workflow keys off that prefix and publishes the paired binaries-linux-gnu/v0.19.4-figma2 with the rebuilt .so. The consuming pin is figma/figma#891051, already open and waiting on the tag.

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{Reviewed by Cursor Bugbot for commit 21c06c8. Configure here.}

[cshi-figma]

claude is saying we have the original and 2 copies (line 99 and line 102), and we could get just one by doing the following, but maybe we can do it in a follow up?

      if inputPtr == nil {
              return nil, errors.New("nil data store set args")
      }

      var args dataStoreSetArgs
      // Decode straight out of the C buffer: json.Unmarshal neither retains nor
      // mutates its input, and the decoded fields are Go-owned copies, so this
      // skips two full-size copies of the args.
      if err := json.Unmarshal(unsafe.Slice(inputPtr, inputLength), &args); err != nil {
              return nil, err
      }
      return &args, nil

[vaidehi-figma]

yeah this makes sense, addressed

[cshi-figma]

claude is also saying that persistent_storage.go needs these same fixes, if we want to add that to a follow up?

[vaidehi-figma]

did it here instead of a follow-up! it's the same three bugs and the same review

[cshi-figma]

left some comments, and maybe we can add some tests later?

but we can def do them in a follow up pr!

[cshi-figma]

claude is saying that &result[0] gives Rust memory thats not reachable from Go when the callback returns, and we are returning the pointer that Rust reads later, so the pointer might not still hold what we wrote to it when we read it

[cshi-figma]

it is suggesting this if helpful

type DataStore struct {
      functions DataStoreFunctions
      ref       uint64

      // The get callback hands Rust a pointer into this buffer, which Rust reads
      // with CStr::from_ptr after the callback has already returned. A local would
      // be unreachable by then. Released on the following get.
      getResultMu   sync.Mutex
      lastGetResult []byte
}

              func(argPtr *byte, argLength uint64) *byte {
                      defer GetFFI().free_string(argPtr)

                      keyStr := internal.GoStringFromPointer(argPtr, argLength)
                      if keyStr == nil {
                              return nil
                      }

                      raw := store.functions.Get(*keyStr)
                      result := make([]byte, len(raw)+1) // zero-filled, so NUL-terminated
                      copy(result, raw)

                      store.getResultMu.Lock()
                      store.lastGetResult = result
                      store.getResultMu.Unlock()

                      return &result[0]
              },

[vaidehi-figma]

interestinggg! addressed (with help of claude). your suggested fix makes sense