Calling `options/1` before shared state finished initializing

[grzuy]

Hi @g-andrade 👋

Thank you for this library!

Been troubleshooting an issue in opentelemetry_exporter package (open-telemetry/opentelemetry-erlang#419 (comment)) which uses tls_certificate_check.

It seems that the init flow in opentelemetry_exporter ends up calling "too quickly" tls_certificate_check:options, before, apparently, tls_certificate_check finished processing the asynchronous cast message that initializes the shared state.

Have you faced this situation before?
Is this the case?
Am I missing something?

Would you be open to some improvement pull request to have some optional synchronization or assurance so that as a user it is possible to know that a call to options will not fail?

Thanks in advance.

[grzuy]

Would something along these lines #62 reasonable to have?

[g-andrade]

Hi @grzuy , thank you for investigating and reporting the issue.

I'm having trouble understanding what's happening. The application should block its dependents from starting until it has made the shared state available:

tls_certificate_check/src/tls_certificate_check_shared_state.erl

Lines 273 to 274 in 1afc616

	ets:insert(?INFO_TABLE, {{latest_shared_state_key, Priority}, Key}),
	proc_lib:init_ack({ok, self()}),

First it writes the shared state the ETS table, and only then does it allow the caller to continue (and therefore allowing dependent applications to start).

---

Ahh, I get it now. Something is calling otel_exporter_otlp, which calls tls_certificate_check:options/1. This something does not depend on tls_certificate_check explicitly, therefore that call can take place while tls_certificate_check is initializing. This is tricky... in such a case tls_certificate_check is an implicit dependency instead of explicit, therefore it may be called while it hasn't even started, much less finished initializing.

[g-andrade]

therefore it may be called while it hasn't even started, much less finished initializing.

And in such a case (not started) a workaround has no option but to try and try again, hoping that the app is indeed starting. But if something went wrong, that wait will loop indefinitely. This would not be ideal.

[g-andrade]

Possible workaround: what if, instead of throwing the exception saying that the application is not started, we try starting it? That way, if it fails to initialize it will throw an error instead of looping indefinitely.

[g-andrade]

Presumably fixed in 661feffd30 / 1.30.0, let me know if further changes are needed. Once again thanks for the report!

[grzuy]

Bumping to v1.30.0 made the throw go away when my application starts.

Thank you 🙏