force_flush should provide a way to let the caller know whether it succeeded, failed or timed out.

From the MeterProvider specification, MetricReader specification and MetricExporter specification:

ForceFlush SHOULD provide a way to let the caller know whether it succeeded, failed or timed out.

Current implementations for readers simply return True, no matter what happened:

MetricReader:
https://github.com/open-telemetry/opentelemetry-python/blob/eed100c3a6828a7cb42b7aa52880d6a355a9acd0/opentelemetry-sdk/src/opentelemetry/sdk/metrics/_internal/export/__init__.py#L397-L399

PeriodicExportingMetricReader:
https://github.com/open-telemetry/opentelemetry-python/blob/eed100c3a6828a7cb42b7aa52880d6a355a9acd0/opentelemetry-sdk/src/opentelemetry/sdk/metrics/_internal/export/__init__.py#L598-L601

And the implementation doesn't allow getting the export result easily, so the only way to manually get the export status seems to be extending the MetricReader, or hooking with a wrapper / mixin.
Is it the desired behavior, or can we return a more indicative status by default?
It looks like _receive_metrics( should pass-through the return value from export( and convert it to bool.

Describe the solution you'd like

A way to let the caller know whether force_flush( succeeded, failed or timed out, i.e. return True iff export succeeded.

UPD:
We better not only convert to bool, but return an Enum type that contains SUCCESS or FAILURE + a failure reason to specify TIMEOUT, for instance. I wonder if it's OK to return MetricExportResult or better create a new Enum.

Anyway, I think that the bool type for force_flush( is not sufficient to comply with the above specification.
Maybe we can change it to an Enum that is bool-convertible and remain backwards-compatible this way. Let me know if it's possible.

Describe alternatives you've considered

Mixin class/inheritance/decorator to hook into MetricReader's export( and use the returned MetricExportResult.

Additional Context

The use case is extremely simple:

Export metrics in a push-based way and check if succeeded.
I'm using the periodic reader in manual mode with the opentelemetry-exporter-prometheus-remote-write exporter, where it's important to NOT lose metrics.

Would you like to implement a fix?

Yes, after the maintainers agree with the change

Start with MetricReader and PeriodicExportingMetricReader in opentelemetry-sdk/src/opentelemetry/sdk/metrics/_internal/export/init.py, especially force_flush and _receive_metrics. Read the linked MeterProvider, MetricReader, and MetricExporter specifications, then trace how export returns its result. Done means force_flush communicates success, failure, and timeout without breaking the intended API contract.