v2.4.0: rg4js doesn't work anymore when called after raygun.js has been fully loaded

I'm loading raygun usign the async snipped from the docs:
!function(a,b,c,d,e,f,g,h) {...}(window,document,"script","//cdn.raygun.io/raygun4js/raygun.min.js","rg4js");

I'm initializing some different settings in different locations of my app using code like rg4js('apiKey', 123); etc. If this code is called before the raygun lib is fully loaded, everything works as expected, but if I call it afterwards, the given setting is not applied.

Some debugging showed me that rayguns executor function is never called, when calling rg4js after the lib has been loaded since rg4js still points to the "barebone" function from the async loading script instead of the actual method from the lib...

This error has been introduced in v2.4.0 whilst v2.3.4 still works as expected.

Thanks for reporting this detailed ticket and apologies for the inconvenience. I'm looking into this now for you and will get back to you soon with a potential fix.

Hi again,

I believe I've found the cause of the bug in 2.4.0, in the case where the library loads first then the snippet options are set by consumer code the options were read from a local variable (stale) instead of from the global options queue on window.rg4js. I've got a pending branch with the fix and have pushed it to the CDN, if you want to update your bootloader snippet to point at http://cdn.raygun.io/raygun4js/2.4.1/raygun.min.js you can verify that the erroneous behavior you were seeing before is fixed.

If there's no further issues this will be released into master later today or tomorrow.

Hi Callum,

thanks for the fast response. I've just tried 2.4.1 which only seems to be working sometimes (at least in my dev environment). Unfortunately I can't give you any further details since I don't have the time to do more debugging right now.

At least I can give you some more insight in how my app interacts with raygun:

Basic initializations from my index.html seem to be working just fine (apiKey, enableCrashReporting etc.). I guess they are always executed before raygun.js is loaded.

Additionally I'm adding an onBeforeSend "interceptor" later on in the app lifecycle after the creation of an ErrorHandler class which adjusts the actual raygun payload by adding some dynamic tags, adding some unique error id, suppressing errors which I don't want to see at raygun etc.

Attaching this interceptor was never working with 2.4.0 and only seems to be working occasionally in 2.4.1.

Fortunately it's no big deal to me right now since I can use 2.3.4 as long as this bug exists.

Please let me know if I can be of any further help!

Hi Callum,

according to your latest release notes it seems like you assume this issue to be fixed?

Unfortunately I'm still experiencing the same issues as described in my previous post with the latest version 2.4.1.

If I execute the code rg4js('onBeforeSend', me._onBeforeRaygunSend);, before the lib has been fully loaded, the handler is not bound correctly and never executed.

Everything is working as expected f i do something like this for testing reasons:

window.setTimeout(function() {
    rg4js('onBeforeSend', me._onBeforeRaygunSend);
}, 5000);

Please let me know if I can give you any further information to help solve the problem!

Edit:

I just realized that it seems as if the issue has somehow been "inverted" since my first post where I described that everything is working as expected if I execute the initialization of the before handler before the lib is loaded, whereas it only seems to be working with 2.4.1 if I execute it after the lib is loaded...

I'd really appreciate some clarification on this...

No change with 2.5.0. Rayguns internal onBeforeSend is never called, if i execute rg4js('onBeforeSend', me._onBeforeRaygunSend); before the lib has been fully loaded.

I'm really frustrated with this by now since I'm stuck with an old version 2.3.4 and haven't received any response at all from Raygun since 5 months...

To clarify this thread, work was progressing behind the scenes on a fix for this very subtle issue. Further responses were customer/site specific and will continue on your Intercom ticket.