SDK breaking lodash on some sites

What to do

• Check whether your product depends on LogRocket. Check your stack

  Paste a package.json, lockfile, Terraform or a list of domains at down.guide/stack to see every provider you depend on.

• Confirm your retries, queues and scheduled jobs caught up after the 0m it lasted.

  Anything that failed between 2021-07-12 14:20 UTC and 2021-07-12 14:20 UTC may need a replay.

• Subscribe to LogRocket's feed to hear about the next one first. RSS feed

  https://down.guide/feed?provider=logrocket works in Slack (/feed subscribe), Discord feed bots and any RSS reader.

Updates from LogRocket 2

1. resolvedJul 12, 2021, 2:20 PM UTC

   We received customer reports that our SDK interfered with the popular lodash library, resulting in broken customer sites. We've rolled back to a known functional version of our SDK. The incident lasted for about an hour and 40 minutes.

   provider

2. postmortemJul 19, 2021, 3:49 PM UTC

   A bug in our build pipeline caused our SDK to expose an internal library globally. As a result, our subset of the lodash library was bound to `window._`, overwriting the existing `_` global for some customer sites. This meant that some expected library functions were not defined after our script loaded. #### Technical Details: * A code change imported all of lodash and accessed a method on the import instead of importing just the method. * Webpack bundled lodash, including its `window._ `assignment despite the library being used in a module import context. #### Remediations: * We’ve added additional tests to catch unwanted pollution of the window object by our SDK * We’ve added an internal linting rule to avoid full lodash imports

   provider

Corrections

None so far.

Something wrong on this page? Report an error or send us a note. Every fix is listed here.