chore: Wait for the replacement flag in the FDv1 fallback spec

[jsonbailey]

Requirements

• I have added test coverage for new or changed functionality
• I have followed the repository's pull request submission guidelines
• I have validated my changes against all supported platform versions

Related issues

Fixes the remaining JRuby failure that #429 deliberately left out of scope. There is no production code change.

#429 attributed this example to a lost wakeup — changed = Concurrent::Event.new being replaced after the first wait returned. That is not what is happening; the current example has a single event and a single wait. The cause is the gate.

Describe the solution you've provided

spec/impl/data_system/fdv2_datasystem_spec.rb, "FDv1 fallback with initializer / falls back to FDv1 and replaces initialized data" released its wait once two flag change events had arrived:

changed.set if changes.length >= 2

and then asserted that the collected keys included fdv1replacementflag.

Applying the FDv1 payload replaces the initializer's data, so it reports the removed flag as well as the added one. Instrumenting the example shows the sequence is always:

["initialflag", "initialflag", "fdv1replacementflag"]

So the count of two is reached on initialflag twice — on every run, on every platform — and changed.set fires from that second delivery while the third is still queued.

Three threads are involved. FDv2 owns a Concurrent::SingleThreadExecutor shared by all four of its broadcasters (impl/data_system/fdv2.rb), and Broadcaster#broadcast hands each listener call to it via executor.post (impl/broadcaster.rb). So the listener runs on that executor thread, not on the data source thread and not on the spec thread. The executor serializes the three deliveries against each other, but it does nothing to stop the spec thread from waking between them — which is exactly what happens: the spec thread returns from changed.wait(3) and evaluates changes.map while the third delivery is still pending.

CRuby's GIL means the executor thread almost always completes the third delivery before the spec thread is rescheduled, so the example passes there. JRuby runs the two threads in parallel and loses the race often enough to fail CI. The observed failure matches:

Failure/Error: expect(flag_keys).to include("fdv1replacementflag")
  expected ["initialflag", "initialflag"] to include "fdv1replacementflag"

The gate now keys on the awaited flag rather than on a count, so the wait cannot return before that flag has been appended:

changed.set if flag_change.key == "fdv1replacementflag"

That is the whole fix. The append precedes the set within a single listener invocation, so a spec thread returning from wait is ordered after every append — a happens-before edge rather than an incidental GIL win.

changes also becomes a Concurrent::Array. This is defensive hardening, not part of the fix: with the gate above, the awaited flag is the last event and nothing is appending while the assertions run. It is there because the collection is written from the executor thread and read from the spec thread, so a future change to the gate — or an additional change event — should not reintroduce an unsynchronized cross-thread read. On JRuby Concurrent::Array includes JRuby::Synchronized; on CRuby it is a bare ::Array subclass.

Describe alternatives you've considered

Raising the gate to changes.length >= 3. It works, and the sequence is deterministic, but it re-encodes the number of events the FDv1 replacement happens to produce. Keying on the flag the assertion is about survives a future change to how replacements are reported.

Leaving changes as a plain array. The gate alone makes the example correct, and the five sibling examples in this file use plain arrays. Concurrent::Array is kept because this example's collection is the one being written from a background executor while the spec thread reads it.

Tagging the example flaky: true, the mechanism this repo already uses for requestor_spec, event_sender_spec, and ldclient_end_to_end_spec. That would have hidden a genuine test bug and cost JRuby coverage of the FDv1 fallback path.

Additional context

The other timing-sensitive concern #429 raised for this file — roughly two dozen waits of 1–3 seconds — is unchanged here. The :218 example it also saw fail is untouched; I have not reproduced that one.

#431 is currently red on JRuby for this same example. Once this merges, rebasing that branch should clear it without any change to its own code.

Validation

• spec/impl/data_system/fdv2_datasystem_spec.rb: 18 examples, 0 failures; 15 consecutive runs of the affected example all passed.
• Full local suite: 1092 examples, 0 failures. The gap against CI is the redis, dynamodb, and consul store specs, which need backing services.
• Event sequence verified by instrumentation across repeated runs, as quoted above.
• RuboCop clean.