Enable custom report stack trace

[Blankwonder]

When using Bugsnag, I encounter the following two issues:

1. Due to the use of dispatch_async, the call stack recorded when calling [Bugsnag notifyError] loses its significance.

2. When using [Bugsnag notifyError] in an extension that cannot access the network, I serialize and save this error for uploading later in the main app, but at that point, the call stack is also meaningless.

Therefore, if it were possible to save the current call stack at a specific moment and then attach it when executing [Bugsnag notifyError], these two needs could be perfectly addressed.

For example:

    NSArray<BugsnagThread *> *threads = [BugsnagThread currentThreads];
    
    dispatch_async( dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,0),^{
        [Bugsnag notifyError:error block:^BOOL(BugsnagEvent * _Nonnull event) {
            event.threads = threads;
            return YES;
        }];
    });

In fact, the threads object of BugsnagEvent is already readwrite; it just lacks a public interface to generate BugsnagThread.

[mclack]

Hi @Blankwonder

There has been a similar discussion in the past and a workaround was suggested, so I'd recommend that you have a read and consider whether a similar implementation may provide a solution for you: #794 (comment)

We do have an item on our backlog to consider implementing a notify variant that would take a block that will be queued for execution after notify returns, but before the event is persisted/delivered. This would allow any complex data to be added, but without blocking the main thread whilst calculating it. I believe this feature would cover your use case, and so I have noted your interest in this with our Product Team. While we don't have an ETA on when this may be fully considered for implementation, we will make sure to update the linked PR if there are any developments on this. As such, I would recommend enabling notifications for that PR, as any potential developments on this feature will be posted there.

I will keep this issue open for now, as we're keen to hear your thoughts on the suggested workaround. Please do let us know if you have any questions.

[Blankwonder]

Thank you @mclack, the current private API can well meet my needs. I will try to call them directly to address the needs. Is there any particular reason why they haven't been made public directly?

As for the variant of notify using block, I might not need it much. The reason I call notify within dispatch_async is not due to performance reasons, but because certain specific operations need to be executed on a dedicated queue. However, there may be exceptions with the passed parameters, so I need to know the call stack before this function calls dispatch_async.

[hannah-smartbear]

Hi @Blankwonder,

the current private API can well meet my needs.

Thanks for confirming this, and for telling us a bit more about your use case.

Regarding the threads API being made public, we have raised this with our engineers, and we will reach back to you if we decide to make this public in future.

[Blankwonder]

Thank you for following up @hannah-smartbear. After testing this method, I discovered an issue: modifying the event.threads attribute only affects the content in the Threads Tab and does not affect the content in the Stacktrace Tab. I wonder if it's possible to allow customization of the Stacktrace content.