Use platform specific host identifier for init logging

[data-sync-user]

Currently, when starting up we do a check for an AWS ID, regardless of what platform we’re starting on. This may cause an exception in some situations because logging initialization occurs before the actix thread management system has been started, which may result in a panic.

┆Issue is synchronized with this Jira Task

[data-sync-user]

➤ Philip Jenvey commented:

JR Conlin I thought #394 ( https://github.com/mozilla-services/autopush-rs/pull/394|smart-link ) fixed the startup issue?

We do init logging within an #[actix_web::main] runtime, the problem was the common-rs was previously using a much older tokio runtime – and removing common-rs and upgrading everything brought the runtime inline with modern actix-web’s.

[data-sync-user]

➤ JR Conlin commented:

Philip Jenvey When I tried running autoendpoint or autoconnect locally without specifying the human logs flag, the app would crash because of the reqwest blocking call. This is with an updated master.

The error I see is:

$ RUST_BACKTRACE=1 cargo run --bin autoendpoint
Finished dev [unoptimized + debuginfo] target(s) in 0.47s
Running target/debug/autoendpoint
thread 'main' panicked at 'Cannot drop a runtime in a context where blocking is not allowed. This happens when a runtime is dropped from within an asynchronous context.', /home/jrconlin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.29.1/src/runtime/blocking/shutdown.rs:51:21
stack backtrace:
0: rust_begin_unwind
at /rustc/eb26296b556cef10fb713a38f3d16b9886080f26/library/std/src/panicking.rs:593:5
...
11: autopush_common::logging::get_ec2_instance_id
at ./autopush-common/src/logging.rs:65:18
12: autopush_common::logging::init_logging::{{closure}}
at ./autopush-common/src/logging.rs:13:62
13: std::sync::once_lock::OnceLock::get_or_init::{{closure}}
at /rustc/eb26296b556cef10fb713a38f3d16b9886080f26/library/std/src/sync/once_lock.rs:170:50
14: std::sync::once_lock::OnceLock::initialize::{{closure}}
at /rustc/eb26296b556cef10fb713a38f3d16b9886080f26/library/std/src/sync/once_lock.rs:296:19
15: std::sync::once::Once::call_once_force::{{closure}}
at /rustc/eb26296b556cef10fb713a38f3d16b9886080f26/library/std/src/sync/once.rs:208:40
16: std::sys_common::once::futex::Once::call
at /rustc/eb26296b556cef10fb713a38f3d16b9886080f26/library/std/src/sys_common/once/futex.rs:124:21
17: std::sync::once::Once::call_once_force
at /rustc/eb26296b556cef10fb713a38f3d16b9886080f26/library/std/src/sync/once.rs:208:9
18: std::sync::once_lock::OnceLock::initialize
at /rustc/eb26296b556cef10fb713a38f3d16b9886080f26/library/std/src/sync/once_lock.rs:295:9
19: std::sync::once_lock::OnceLock::get_or_try_init
at /rustc/eb26296b556cef10fb713a38f3d16b9886080f26/library/std/src/sync/once_lock.rs:218:9
20: std::sync::once_lock::OnceLock::get_or_init
at /rustc/eb26296b556cef10fb713a38f3d16b9886080f26/library/std/src/sync/once_lock.rs:170:15
21: autopush_common::logging::init_logging
at ./autopush-common/src/logging.rs:13:31
22: autoendpoint::main::{{closure}}
at ./autoendpoint/src/main.rs:43:5
23: <tokio::task::local::RunUntil as core::future::future::Future>::poll::{{closure}}
at /home/jrconlin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.29.1/src/task/local.rs:923:42
...
50: actix_rt::runtime::Runtime::block_on
at /home/jrconlin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/actix-rt-2.8.0/src/runtime.rs:82:9
51: actix_rt::system::SystemRunner::block_on
at /home/jrconlin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/actix-rt-2.8.0/src/system.rs:210:9
52: autoendpoint::main
at ./autoendpoint/src/main.rs:36:1
53: core::ops::function::FnOnce::call_once
at /rustc/eb26296b556cef10fb713a38f3d16b9886080f26/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.

This patch allows me to run correctly.

From what I could tell, it was because the blocking call we were doing which tells me that actix had not yet fully established the async handler. Tossing the reqwest request into a mini thread seemed to resolve the problem. I’m still not 100% on threads, so I’m probably missing something, but does this make sense?

[data-sync-user]

➤ JR Conlin commented:

no longer required