Resolved incident
SDK breaking lodash on some sites
LogRocket · Major · Started
- Duration
- < 1m
- Severity
- Major
- Status
- Postmortem
Summary
Major · Postmortem
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
Event timeline
How this incident unfolded, from the official status page.
Postmortem
LogRocket
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
Resolved
LogRocket
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.