onReady() listener doesn't work when fresh installing the app having pooling disabled.

[jnavarro98]

Describe the bug

Initializing unleash with .pollingStrategy.enabled(false) when fresh installing the app doesn't trigger onReady() listener.

However if the app was installed and had pooling enabled, then changed to pooling disabled, onReady() is called correctly.
It seems that in order to have the listeners working, you have to have pooling enabled at least once.

This makes .pollingStrategy.enabled(false) useless for our use case (we block the app launch relying in this listener).

Our workaround was to have pooling enabled with .pollingStrategy.interval(Long.MAX_VALUE)

Steps to reproduce the bug

Have unleash initialized with .pollingStrategy.enabled(false)

Expected behavior

onReady() is called when sdk is initialized

Unleash version

1.0.1

Subscription type

Enterprise

Hosting type

Self-hosted

[gastonfournier]

@jnavarro98 I'm trying to understand this. If you're never polling the SDK will never be ready unless you provide a bootstrap, in which case the SDK will be ready as soon as the bootstrap file is read.

If you want to have polling disabled you need to explicitly tell unleash to do at least one fetch of the features configuration. If the SDK has not seen any configuration (either from polling or from a bootstrap) it won't be ready.

You can see many of our tests cover this use case, this is just an example:

unleash-android/unleashandroidsdk/src/test/java/io/getunleash/android/DefaultUnleashTest.kt

Lines 146 to 174 in 5e0519a

	.pollingStrategy.enabled(false)
	.metricsStrategy.enabled(false)
	.localStorageConfig.enabled(false)
	.forceImpressionData(true)
	.build(),
	unleashContext = UnleashContext(userId = "123"),
	lifecycle = mock(Lifecycle::class.java)
	)
	var ready = false
	val impressionEvents = mutableListOf<ImpressionEvent>()
	unleash.start(
	eventListeners = listOf(object : UnleashReadyListener, UnleashImpressionEventListener {
	override fun onImpression(event: ImpressionEvent) {
	println("Impression event received: ${event.featureName}")
	impressionEvents.add(event)
	}
	override fun onReady() {
	ready = true
	}
	}), bootstrap = listOf(
	Toggle(name = "with-impression-1", enabled = true, impressionData = true),
	Toggle(name = "with-impression-2", enabled = true, impressionData = true),
	Toggle(name = "with-impression-3", enabled = true, impressionData = true),
	Toggle(name = "without-impression", enabled = false)
	)
	)
	await().atMost(1, TimeUnit.SECONDS).until { ready }

To manually trigger 1 fetch an never poll again you have the following methods:

unleash-android/unleashandroidsdk/src/main/java/io/getunleash/android/Unleash.kt

Lines 32 to 42 in 730bc21

	/**
	* This function forces a refresh of the toggles from the server and wait until the refresh is complete or failed.
	* Usually, this is done automatically in the background, but you can call this function to force a refresh.
	*/
	fun refreshTogglesNow()
	/**
	* This function forces a refresh of the toggles from the server asynchronously using the IO dispatcher.
	* Usually, this is done automatically in the background, but you can call this function to force a refresh.
	*/
	fun refreshTogglesNowAsync()

Let me know if I misunderstood your request, but initially it doesn't seem like a bug.

[gastonfournier]

We've added #90 that is a very specific test for this particular use case

[jnavarro98]

Thanks for the clarification. I found that the documentation in your website is quite lacking. When I call unleash.start I expect it to at least fetch flags, I shouldn't have to do reverse engineering to understand the behaviour of an sdk. There were many times where I had to figure out many things by looking at your code. For example the Heartbeat listener, needing to have the unleash.start in the main thread (or else it crashes) and many other features your SDK provide aren't documented.

This is not acceptable for an SDK. Please work on the documentation.

[gastonfournier]

When I call unleash.start I expect it to at least fetch flags

Our assumption is that when you set the polling strategy to disabled, you don't want to poll (therefore you don't fetch flags), but maybe you understand it differently. I could see another way of understanding "polling disabled" is "continuous polling is disabled, but at least the SDK will fetch once". On the other hand, we have users that don't want that initial fetch because they want to control when that happens so we need to account for both.

When I call unleash.start I expect it to at least fetch flags, I shouldn't have to do reverse engineering to understand the behaviour of an sdk. There were many times where I had to figure out many things by looking at your code. For example the Heartbeat listener, needing to have the unleash.start in the main thread (or else it crashes) and many other features your SDK provide aren't documented.

This SDK is quite new, and as that the documentation is also quite fresh. We tried to support many different use cases (fetch, don't fetch, fetch once, fetch when the customer wants, etc), so that creates quite a lot of different combinations to cover. The ones that are documented in the website are the basics, but we will continue to improve them based on feedback or external contributions. If you have a snippet of what failed in your setup or how you ended up configuring your SDK for your use case we can add that, or if you have a suggestion how to make the polling configuration clearer we can also look into that.

[jnavarro98]

At least have documented every function we can use from unleash.

For our use case, we wanted to block the application start until unleash is ready and do a single fetch at start, we used a suspend coroutine. That is why it was important to know that if we disabled the pooling it wouldn't be called unless we pass the bootstrap and we would be blocked waiting for a callback that never comes.

Now that we disabled pooling and added the bootstrap, we also had to fetch the toggles manually (which seems redundant and adds complexity, start could know when to do the fetch, in my opinion if you want to start unleash you want to get the flag values).

It would be useful to add the case of pooling disabled in the documentation, what do you need to do. Many developers don't want to alter the status of their feature flags in runtime since it adds complexity and gives almost no value in our case.

[gastonfournier]

Thanks for the snippets! I'll try to do that next week and share a PR here.

At least have documented every function we can use from unleash.

Software is an iterative process and we'll get there eventually, but it's a moving target. Every piece of help we get from the community such as what you did, helps us make the product better. Thank you!