TracerProvider::forceFlush should be an API method?

[brettmc]

Currently, TracerProvider::forceFlush is an SDK method, which matches the specification
We also document that instrumented code should only rely upon the API

But, if I am instrumenting an application based on react/swoole/roadrunner/etc where one process can serve many requests, I would like to be able to flush traces upon a condition such as request completion or timer. Traces would eventually be exported by a later request or shutdown, but that could be a long time depending on traffic.

$tracerProvider = \OpenTelemetry\API\Common\Instrumentation\Globals::tracerProvider(); // API tracerprovider, could be a no-op

while ($request = $worker->waitRequest()) {
    try {
        $response = $app->handle($request);
        $worker->respond($response);
    } catch (\Throwable $t) {
        $worker->getWorker()->error($t->getMessage());
    }
    // check interface to see if forceFlush is available
    if ($tracerProvider instanceof \OpenTelemetry\SDK\Trace\TracerProviderInterface) {
        $tracerProvider->forceFlush();
    }
}

In the above example, I need to check whether I have an SDK instance to know if I can force flush, thus breaking the "depend only on the API" directive...

[Nevay]

Related spec issue: open-telemetry/opentelemetry-specification#2944

I would like to be able to flush traces upon a condition such as request completion or timer.

React and Swoole applications should use a SpanProcessor that utilizes the underlying event loop to flush periodically after scheduledDelayNanos.
Roadrunner applications could use a non-blocking Relay or use a SpanProcessor that autoflushes on a specific condition, e.g. after every server span (open-telemetry/opentelemetry-specification#2944 (comment))

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[brettmc]

Closing this, I don't think the spec is going to change. As a future solution, I think that after GA release, we can look to implement better async capabilities into batch processors, based on some prior with from Nevay (which will likely require 8.1+, and a v2 release of the SDK)