(feature) A mechanism for blocking on the initial flag load about go-feature-flag

[thomaspoignant]

Hey @jamesmulcahy thanks for opening this issue.
Can you provide a more detailed description of the problem you're facing? It would be awesome if you could explain in detail what you've discovered.

Do you have some code examples that I can use to reproduce it?

What you are looking for is a way to wait that the initial loading to be complete before being able to evaluate the flag?

[jamesmulcahy]

What you are looking for is a way to wait that the initial loading to be complete before being able to evaluate the flag?

Yes, exactly right.

The issue right now is that if I write a test which depends on feature flag configuration, the execution of the test races against the background loading of the feature flag configuration. This leads to the test failing sporadically.

The workaround I'm using for now is to add this at the top of tests which I know are loading flags:

func WaitForInit(t *testing.T) {
	require.Eventually(t, func() bool {
		flags, err := ffclient.GetFlagsFromCache()
		return err == nil && len(flags) > 0
	}, 1*time.Second, 50*time.Millisecond)
}

But I'd prefer a more generic approach, for example, if there was a ffclient.GetInitializationChan() which returned a channel which was closed once the initial flag load was complete. That way, I could write something like this:

ffclient.Init(...)

<-ffclient.GetInitializationChan()

Or if people wanted something more advanced/robust, they could add a timeout...

ffclient.Init(...)

select {
  case <-ffclient.GetInitializationChan()
    // Success!
  case <-time.Tick(1 * time.Second)
    // Timeout, failure...
}

I'd be happy to put together a PR along these lines (or another approach, if you have another idea/preference)

[thomaspoignant]

@jamesmulcahy I was reading the code again and I am not sure to understand why you have this problem.
The Init function is doing the first load of the flag in a synchronous way in the same thread as the init function.

The thread is following these steps:

Init()
  --> New()
    --> retrieveFlagsAndUpdateCache(goFF.config, goFF.cache) // at this stage the flags are supposed to be loaded already
      --> goFF.startFlagUpdaterDaemon() //We launch the daemon to update the flag in the background 

You can check the initial load here.

It means that after your call of the Init function, the loading of the flags is supposed to be already ok.
If you occur race conditions maybe something is not working as expected.

Do you have an example of a test to help me to reproduce the issue?

[jamesmulcahy]

Interesting point, thanks for taking a look so closely.

EDIT: Removed incorrect theory on the bug.

I don't have an independent test that reproduces this (it's heavily coupled with some internal/private source code), but let me see if I can put one together -- rather than continuing to speculate about the behavior. I'll get back to you shortly!

[thomaspoignant]

@jamesmulcahy were you able to reproduce?
If so I will be interested to dig more in detail on the problem.

[github-actions]

This issue was closed because it has been stalled for 5 days with no activity.