Feature/real time flags

[matthewelwell]

Description

This PR adds the real time flags feature as described in #18 and Flagsmith/flagsmith#1498

Fixes #18

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Because the real-time updates are dependent upon the the operation of the SSE functionality I found it best to write end-to-end integrations test for this feature. They test the main 'update' scenario, as well as ensuring that the SSE connection reconnects. It

Test Configuration:

As these are integration tests they need some environment variables to connect to an account, feature and value. These are at the top of the integration test and follow the format seen in the existing documentation:

    // You'll need a valid account to test this
    private val environmentKey = System.getenv("ENV_KEY")
    private val authToken = "Token " + System.getenv("API_TOKEN")
    private val featureId = System.getenv("FEATURE_ID") ?: "integration-test-feature"
    private val featureStateId = System.getenv("FEATURE_STATE_ID") ?: "313512"

To skip the integration tests you can run the gradle command as shown in the build.gradle:

    // if the excludeIntegrationTests property is set
    // then exclude tests with IntegrationTest in the name
    // i.e. `gradle :FlagsmithClient:testDebugUnitTest --tests "com.flagsmith.*" -P excludeIntegrationTests`
    if (project.hasProperty("excludeIntegrationTests")) {
        exclude {
            it.name.contains("IntegrationTest")
        }
    }

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• The code is peer-reviewed
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[matthewelwell]

@gazreese I've been through everything apart from the tests here (since they may yet change due to current failures).

One thing I've noticed however, is that we only have the integration tests. Are we planning to also add some unit tests for some of the more complex logic?

[gazreese]

So the recent updates do a few things. I've simplified the way that the events get pushed to the live event stream on update, making this completely passive based on a successful getFlags() call rather than doing anything with the flags directly in the realtime updates logic. This should be easier to maintain and doesn't repeat as much code.

https://developer.android.com/kotlin/flow/test#stateflows The testing StateFlows docs suggest polling the .value within unit tests for testing. I had a more reactive style initially, but due to some threading / coroutine issues this could well have been the cause of the issues on GH actions.

I also noticed 100% CPU on the Java process while testing. I added some wait() statements in the loops (which were tighter since polling the value) and that seems to have been the final push that got them running.

[gazreese]

Code to go with the comments coming shortly

[gazreese]

@matthewelwell re:

One thing I've noticed however, is that we only have the integration tests. Are we planning to also add some unit tests for some of the more complex logic?

We currently use https://www.mock-server.com/ to mock the HTTP responses and unit test most of the functionality. Unfortunately neither MockServer or anything else I can find will mock SSE for us, so we can't do much useful testing without an integration test.

Also, in the absence of an example app in the repo, I was much more confident in the implementation having done the integration tests and talking to the real servers.

The only real logic in our SSE implementation is to reconnect on errors and things like that. We're reliant on the SSE library for much of the actual implementation, so the sensible approach is to either integration test or mock the HTTP.