But FailedRequestStatusCodes does not exist on the BindableSentryOptions.
Ideally as many of the options as possible would also be configurable via bindings (e.g. apssettings.json).
I think I didn't solve for FailedRequestStatusCodes specifically because the broader AOT problem was huge in scope. The shortest path to completion was simply to omit any non trivial properties (primitives) from the bindable options and require SDK users configure these instead via code.
I'm not really sure how many people will use the configuration bindings for these two properties, so a relatively simple solution to start with is probably not a bad thing. This PR adds the ability to configure lists of explicit codes to ignore via bindings... if people want to do more complex things like ranges, that would have to be done in code.
We could create a custom binding that was more sophisticated... it's certainly technically possible but would date longer to build and test. We have a backlog of over 300 issues so I'd recommend we just go with this simpler solution for the time being (or omit the ability to configure trace ignore status codes via bindings entirely).
We could also, for consistency, add an issue to the backlog to enable some similar bindable options for FailedRequestStatusCodes... with a medium priority initially (unless we get feedback from the community that this would be useful).
Originally posted by @jamescrosswell in #5034 (comment)
Ideally as many of the options as possible would also be configurable via bindings (e.g. apssettings.json).
I think I didn't solve for
FailedRequestStatusCodesspecifically because the broader AOT problem was huge in scope. The shortest path to completion was simply to omit any non trivial properties (primitives) from the bindable options and require SDK users configure these instead via code.I'm not really sure how many people will use the configuration bindings for these two properties, so a relatively simple solution to start with is probably not a bad thing. This PR adds the ability to configure lists of explicit codes to ignore via bindings... if people want to do more complex things like ranges, that would have to be done in code.
We could create a custom binding that was more sophisticated... it's certainly technically possible but would date longer to build and test. We have a backlog of over 300 issues so I'd recommend we just go with this simpler solution for the time being (or omit the ability to configure trace ignore status codes via bindings entirely).
We could also, for consistency, add an issue to the backlog to enable some similar bindable options for FailedRequestStatusCodes... with a medium priority initially (unless we get feedback from the community that this would be useful).
Originally posted by @jamescrosswell in #5034 (comment)