Allow removal of verbose “Unable to resolve host” log entries

[PattaFeuFeu]

Expected Behaviour

I would like to be able to set up Amplitude so that it doesn’t constantly log

Error when upload event: Unable to resolve host "api2.amplitude.com": No address associated with hostname

Current Behaviour

My logs are bombarded with the log entries mentioned above.

I’m getting these issues because an app I work on connects to IoT devices via Wi-Fi. If no other cellular connection is available or if the device the app is running on doesn’t support Wi-Fi STA/STA concurrency, the Amplitude SDK won’t be able to send events in real-time for quite a while until a user disconnects from the connected device.

I assume the same would happen if users block Amplitude using privacy VPNs on their Android devices, Pi-Hole or similar on their network, or a privacy-conscious DNS server for lookup of IP addresses.

Possible Solution

Either don’t log that event at all, or allow us to limit logging an an opt-out basis

Steps to Reproduce

1. On a device that generally has Wi-Fi connectivity, install an app with Amplitude Kotlin SDK
2. Open the app
3. Turn Wi-Fi off or connect to a Wi-Fi that doesn’t have an Internet connection or cannot resolve the host api2.amplitude.com

Environment

• Device: Samsung Galaxy M12 (Android 11), Samsung Galaxy S21+ (Android 12)

[niqo01]

It would be great if the LoggerProvider had a way to filter our connectivity related issues. Here is the one I am filtering out from Amplitude:

                if (lowercase.contains("unable to resolve host")
                    || lowercase.contains("failed to connect to")
                    || lowercase.contains("timeout")
                    || lowercase.contains("connection closed by peer")
                    || lowercase.contains("connection abort")
                    || lowercase.contains("unexpected end of stream")
                    || lowercase.contains("connection reset by peer"){

[liuyang1520]

Hi @PattaFeuFeu ,

Thanks for reporting this! It is actually customizable by implementing your own logger, see example, also check @niqo01 's example above too. We also provide a log level configure, to filter out/disable logs if needed.

The above log you mentioned is important to identify the issue, so I think we should keep it in the default logger. But again, if you don't need it, feel free to customize the logger and filter it out.

Thanks!

[PattaFeuFeu]

Thanks for the nice “RTFM” @liuyang1520—I should have checked it before 🙈 That should help quite a bit. Thanks!

The above log you mentioned is important to identify the issue, so I think we should keep it in the default logger. But again, if you don't need it, feel free to customize the logger and filter it out.

Nah, as a default that absolutely makes sense. 😊