[SPACETIME][FTR] statically defined dependency graphs for config files of tests

[wayneseymour]

Statically Defined Config Files

Since EffectTS Effects are defined as:

type Effect<Success, Error, Requirements> = (
  context: Context<Requirements>
) => Error | Success

Also, due to the fact that the Effect type has three type parameters with the following meanings:

Success. Represents the type of value that an effect can succeed with when executed. If this type parameter is void, it means the effect produces no useful information, while if it is never, it means the effect runs forever (or until failure). Error. Represents the expected errors that can occur when executing an effect. If this type parameter is never, it means the effect cannot fail, because there are no values of type never. Requirements. Represents the contextual data required by the effect to be executed. This data is stored in a collection named Context. If this type parameter is never, it means the effect has no requirements and the Context collection is empty.

Requirements type parameter could be used to define a layer of config files, needed to start at an FTR test, if we strongly typed the config files.

Unless I've missed my guess, we'd be able to statically see the dependency graph of the runtime, but at compile time. If that's true, then we should be able to statically observe all things a test needs, if we we define them as Effects.

BIG IDEA We're going back to college where functions have a contract of what they accept and what they produce, including statically defined error handling, kinda like Java methods with exceptions.

More on Layers

A Layer<RequirementsOut, Error, RequirementsIn> represents a blueprint for constructing a RequirementsOut. It takes a value of type RequirementsIn as input and may potentially produce an error of type Error during the construction process.

In our case, the RequirementsOut type represents the service we want to construct, while RequirementsIn represents the dependencies required for construction.

^^ becomes

In our case, the RequirementsOut type represents the final config we want to construct, while RequirementsIn represents the config required for construction

As much as I'm not personally a fan of Classes, we could define Effects as classes, that depend on other config classes, without using inheritance (just effect compositions).

• [ ] instrument ci for effect
• [ ] prove we can start a simple test with dependencies, within ftr constructs
• [ ]

[elasticmachine]

Pinging @elastic/appex-qa (Team:QA)