You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm curious if there is any interest in increasing the general utility of the BugsnagNetworkRequestPlugin, especially for GraphQL APIs. What if, at the very least, the request and response bodies were sent over to Bugsnag?
By default, the URLRequests sent by GraphQL APIs don't end up providing very useful information when they make it over to Bugsnag: every request has the same URL, for example.
Describe the solution you'd like
Since the BSGURLSessionTracingDelegate has access to the NSHTTPURLResponse when it comes time to log, what if we exposed a way for clients to parse the Data to a String however they'd like (I wouldn't want to assume JSON, but I'm interested in JSON personally) and that was included in the error information that gets sent up to Bugsnag?
Describe alternatives you've considered
I'm aware of the ability to make some changes here server-side, but I'm mostly interested in having the bodies themselves show up in Bugsnag – regardless of whatever the web can do to change the URLs themselves.
Additional context
This would make the plugin extremely useful for me, and I would prefer a built-in approach instead of dropping the plugin altogether and adding additional logging myself.
The text was updated successfully, but these errors were encountered:
Hi @gonzalonunez - thanks for the suggestions, this sounds like it would be a useful addition to the BugsnagNetworkRequestPlugin! We're already looking at investigating better support for GraphQL across our notifier librariers so I've flagged this use case with our product team. I'll keep you updated on this thread when there are any changes!
Since the BSGURLSessionTracingDelegate has access to the NSHTTPURLResponse when it comes time to log, what if we exposed a way for clients to parse the Data to a String however they'd like (I wouldn't want to assume JSON, but I'm interested in JSON personally) and that was included in the error information that gets sent up to Bugsnag?
Personally I think this would be bad to do holistically.
That said, it would be great if the plugin supported configuration.
My proposal would be a block API that the network plugin accepts to persist additional metadata.
In my particular use case, I would like to capture a tracing header that I originally sent to the backend.
E.g.:
Description
I'm curious if there is any interest in increasing the general utility of the
BugsnagNetworkRequestPlugin
, especially for GraphQL APIs. What if, at the very least, the request and response bodies were sent over to Bugsnag?By default, the
URLRequest
s sent by GraphQL APIs don't end up providing very useful information when they make it over to Bugsnag: every request has the sameURL
, for example.Describe the solution you'd like
Since the
BSGURLSessionTracingDelegate
has access to theNSHTTPURLResponse
when it comes time to log, what if we exposed a way for clients to parse theData
to aString
however they'd like (I wouldn't want to assume JSON, but I'm interested in JSON personally) and that was included in the error information that gets sent up to Bugsnag?Describe alternatives you've considered
I'm aware of the ability to make some changes here server-side, but I'm mostly interested in having the bodies themselves show up in Bugsnag – regardless of whatever the web can do to change the URLs themselves.
Additional context
This would make the plugin extremely useful for me, and I would prefer a built-in approach instead of dropping the plugin altogether and adding additional logging myself.
The text was updated successfully, but these errors were encountered: