implement PerfBackgroundJsonValidation feature-flag

[colesnodgrass]

What

• builds on add perf feature-flag; ensure compatability with LaunchDarkly (LDv5) users #21534
• add support for checking the PerfBackgroundJsonValidation feature-flag within the RecordSchemaValidator class

How

• start plumbing in the FeatureFlagClient in all the necessary places to get feature-flag support within the RecordSchemaValidator

  • the existing FeatureFlags is still present in these files as I wanted to limit the scope changes to implement this single PerfBackgroundJsonValidation flag

• this feature-flag doesn't do anything other than change a log message, once functionality has been verified, this will be updated to do real work

• the feature-flag check is done in the following way:

  if (workspaceId != null) {
    if (ffClient.enabled(PerfBackgroundJsonValidation.INSTANCE, new Workspace(workspaceId))) {
      log.info("feature flag enabled for workspace {}", workspaceId);
    } else {
      log.info("feature flag disabled for workspace {}", workspaceId);
    }
  } else {
    log.info("workspace id is null");
  }

  I am unsure if a workspaceId will exist at this point in the code (the syncInput object supports a workspaceId but doesn't require one)

Lessons Learned

Micronaut property checking issues

Micronaut does not handle the following situation well:

if property P is defined and P is a non-empty string, then return bean A, else return bean B

Instead redefine the situation as:

if property P is defined and equals a well known value, then return bean A, else return B_

To summarize use @Requires(property=P, value=WELL_DEFINED) with @Requires(property=P, notEquals=WELL_DEFINED). Do not use @Requires(property=P) with @Requires(missingProperty=P) or @Requires(property=P, pattern=NON_EMPTY_REGEX) with @Requires(property=P, pattern=EMPTY_REGEX)

This also appears to be related to this Micronaut issue

Micronaut Kotlin Dependencies

I spent a lot of time with trying to get the Kotlin beans injectable into the java code. What should just work doesn't and it well documented on the Micronaut side as to what exactly is required (or at least I never found the documentation). After many attempts I and looking at the auto-generated kotlin Micronaut projects I landed on kapt being necessary in kotlin projects. Even this isn't entirely true.

If the Kotlin project is defined with the following gradle setup, the beans will not be visible to java projects (and possibly other projects as well):

plugins {
    kotlin("jvm") version "1.8.0"
}

dependencies {
    annotationProcessor(platform(libs.micronaut.bom))
    annotationProcessor(libs.bundles.micronaut.annotation.processor)
}

But they will be visible with the following setup:

plugins {
    kotlin("jvm") version "1.8.0"
    id("io.micronaut.minimal.application") version "3.7.0"
}

dependencies {
    annotationProcessor(platform(libs.micronaut.bom))
    annotationProcessor(libs.bundles.micronaut.annotation.processor)
}

micronaut {
  version("3.8.2")
}

and also visible with the following setup:

plugins {
    kotlin("jvm") version "1.8.0"
    kotlin("kapt") version "1.8.0"
}

dependencies {
    kapt(platform(libs.micronaut.bom))
    kapt(libs.bundles.micronaut.annotation.processor)
}

I went with the kapt solution.

It's worth noting that kapt is deprecated and is being replaced with kps in Micronaut 4 (this is a good thing).

[github-actions]

Airbyte Code Coverage

File	Coverage [21.16%]	❌
RecordSchemaValidator.java	95.08%	🍏
ContainerOrchestratorFactory.java	92.45%	🍏
ReplicationJobOrchestrator.java	11.67%	❌
ReplicationActivityImpl.java	0.65%	❌
TestConfigHelpers.java	0%	❌

Total Project Coverage	24.51%	❌

[CLAassistant]

All committers have signed the CLA.

[davinchia]

is this a koitlin specific annotation processor?

[davinchia]

what about the separate threading changes? Or does this PR only include the feature flag changes?

[davinchia]

also to confirm, we'll opt in workspaces via adding the workspace id in LauchDarkly?

[colesnodgrass]

This only includes the feature-flag changes. A quick, follow-up PR will add in the actual changes that will be contained within the feature-flag.

This allows me to vet that the client is working as expected and seeing updated from LaunchDarkly without having an impact on any users.

[davinchia]

@colesnodgrass I think we are going to have a merge conflict. Do you mind letting me merge in my PR first before we merge in yours?