impr: Use loaded configuration when fetching for global config

[speeddragon]

When we modify the default configuration using the HB_CONFIG environment variable, it will not be available when fetching hb_opts:get. This will call global_get and config_lookup that will fetch the default_message instead of the current configuration.

The behaviour that triggered this issue was that setting new routes via HB_CONFIG wouldn't be used when load_routes was called.

The hb_opts:get(routes, [], Opts); call would return the hb_opts:default_message/0 instead of the loaded from HB_CONFIG.

Side quest

Looking into the code, routes can't be fetched from the Opts (in this case, Opts is the Store Options) when we set up via HB_CONFIG. The key is always a string, and the requested key is an atom. Maybe this logic could be revised in the future.

[speeddragon]

Same failed/flaky tests from edge and #553

Failed: 5.  Skipped: 0.  Passed: 1371.

[samcamwilliams]

The key should be in the Opts from the HTTP server already if it was loaded correctly during boot? It sounds like either your side quest issue (which should have been mitigated by mimic_default_types in hb_opts, IIRC), or losing the HTTP server's Opts somewhere in the flow is the real culprit?

[speeddragon]

The key should be in the Opts from the HTTP server already if it was loaded correctly during boot? It sounds like either your side quest issue (which should have been mitigated by mimic_default_types in hb_opts, IIRC), or losing the HTTP server's Opts somewhere in the flow is the real culprit?

I'm pretty sure that I've tried loading the routes via the Store configuration, and I've seen <<"routes">> instead of routes atom. I will double-check it tomorrow and understand, if that is the case, why mimic_default_types isn't working.

[samcamwilliams]

Awesome -- thank you.

I'm pretty sure that I've tried loading the routes via the Store configuration, and I've seen <<"routes">> instead of routes atom

The store config opts are a pretty dubious area at the moment. This speaks to our discussion of device-ifying the stores earlier.

IIRC, the mimic_default_types function I referenced above may only mimic the types of root-level keys? That could also be a source of the issue here.

[speeddragon]

Closing this in favor of #563.