Graceful degradation of error logging about raygun4py HOT 9 CLOSED

Thanks for reporting this one, if possible I'd like to get the provider tightened up for your use case here. If I've read the stack and scenario correctly the raygunmsgs.py platform.architecture()[0] call is failing, and you'd like a best-effort approach for getting the environment data so that it doesn't result in unhandled exceptions - is the right?

If that's the case one approach would be to guard set_environment_details with an except, this approach is used in several of our other providers as access to environment data varies wildly between sub-frameworks. This would surface the safe properties first so it should degrade nicely and send the available env data without spamming your logs. Does this sound like what you're looking for?

from raygun4py.

Yes I think that's the case. I'm advocating for always raising an error to raygun, even if it's skinnier than normal rather than dropping the error to the log file.

Thanks, Alex

On 11 Oct. 2016, at 21:17, fundead [email protected] wrote:

Thanks for reporting this one, if possible I'd like to get the provider tightened up for your use case here. If I've read the stack and scenario correctly the raygunmsgs.py platform.architecture()[0] call is failing, and you'd like a best-effort approach for getting the environment data so that it doesn't result in unhandled exceptions - is the right?

If that's the case one approach would be to guard set_environment_details with an except, this approach is used in several of our other providers as access to environment data varies wildly between sub-frameworks. This would surface the safe properties first so it should degrade nicely and send the available env data without spamming your logs. Does this sound like what you're looking for?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

from raygun4py.

Great, yeah that sounds like the right sort of behavior we should have. I'll ensure that a work item for this is put on the roadmap and fixed in the near term for you.

from raygun4py.

Thanks, what kind of an ETA are we looking at for this? Days/Weeks/Months?

Got a couple of pretty painful errors I need to work around if this is going to be a while.

from raygun4py.

I'll get a release out for you today containing a fix for this (next few hours).

e: Unfortunately I ran out of time to get this released, there's a PR at #51 but I need to port your implementation (thanks for the PR by the way, big help) and add a couple unit tests to fix the coverage. This should be live on Monday NZDT.

Regards,

Callum Gavin
Raygun Limited

from raygun4py.

Great thanks Callum

from raygun4py.

Hey Callum, any news on this one?

from raygun4py.

Hi Alex,

Unfortunately yesterday was a public holiday here so I've only just been able to get back into the office and finalize the PR. This is now complete and has been released as v3.1.3 on PyPI. Hope this fixes the noise in your logs and you continue to find Raygun useful.

Regards,

Callum Gavin
Raygun Limited

from raygun4py.

No problems Callum, thanks for the quick turn around. Really appreciate the effort! 😄

from raygun4py.