Open mattheworiordan opened 5 years ago
Assigned @SimonWoolf and @paddybyers for review
➤ Simon Woolf commented:
this is an issue for quintin not me, reassigning
➤ Automation for Jira commented:
The link to the corresponding Jira issue is https://ably.atlassian.net/browse/SDK-2805
Background
When customers experience a crash and report this to the Ably support team, it's considerably more difficult for us to help them without verbose logs. As such, we often tell customers to enable verbose logging and send us the logs, but this presents a few issues:
Somewhat related to this, we added (optional) functionality to the spec to that allows exceptions to be caught and sent to our own exception tracking service. The purpose of this was also to help us identify issues customers are having and get fixes out more quickly.
We also added a spec item to handle failures as gracefully as possible, see https://docs.ably.io/client-lib-development-guide/features/#RSC20a.
Proposal
I propose we consider adding the following functionality to the libraries, which if agreed, I can update the spec for review:
client.util.getCrashDump()
which returns a plain text formatted string constructed from:ClientOptions.log.crashDumpBufferLength
bytes (perhaps default 32KiB) from verbose logs. Note that the standard log level has no impact on the getCrashDump log level.ClientOptions.log.crashDumpLogLevel
will default to the most verbose levelClientOptions.log.crashDumpObfuscate
is true (default true)ClientOptions.log.crashDumpEnabled
is true (default false in 1.* at least), then an exception is raised when calling this method.RSC20a
is in fact implemented correctly.getCrashDump
at the time of sending the exception.┆Issue is synchronized with this Jira Task by Unito