Global state issues

[asadsalman]

Describe the bug I'm trying to use flank as a library in a kotlin project and calling the following code in a loop:

val newargs = arrayOf("firebase","test","android","run", "-c", "flank.yml", "--dump-shards")
listOf(1,2,3).forEach {
    startDurationMeasurement()
    CommandLine(MainCommand()).execute(*newargs)
    closeCrashReporter()
    outputReport.generate()
    printTotalDuration()
}

(Not using withGlobalExceptionHandling because it kills the calling process.)

startDurationMeasurement(), closeCrashReporter(), outputReport.generate(), printTotalDuration() all affect global state, and give incorrect output if I use them in a loop (or, more importantly, in parallel).

To Reproduce Place the above quoted code in MainKt.main. You might have to provide a path to flank.yml. You will see that while the duration of the first invocation is fine, the duration of the second and third invocation will be 0-1s.

Expected behavior

It would be great that duration measurement/reporting/crash reporting could be encapsulated inside a flank invocation instead of global so that running more than one invocation from code would not affect each other.

Additional context I'm calling flank from Kotlin code, not using the jar directly.

[bootstraponline]

@jan-gogo will the architecture resolve global state? Ideally Flank could be used as a library to have multiple flank instances in parallel. Today this isn't possible due to global state.

[jan-goral]

@bootstraponline Hey, sorry for the late answer. The architecture by itself doesn't say anything about having a global state or not, it's rather about organizing code on different layers of abstraction. The global state is a result of probably wrong implementation choices that, I hope can be rather easily fixed for improving the overall experience.

For this issue, I am recommending an investigation to localize places where global state occurs, as a first step. The next step will be a solution design for converting the global state into the local, which should allow running multiple executions, each with an isolated state.

Additionally, could be helpful that new architecture design is specifying the execution context which looks like a good place for keeping the runtime dependencies. The Corellium MVP can be example how to solve the internal execution state problem.

[bootstraponline]

@jan-gogo Sounds good!