In my opinion the accepted answer is only partially correct.
Clearing your localStorage will clear this issue for your specific user. However for other visitors that still have this value in localStorage they will still trigger the error on their browser - and thus in NewRelic.
Specifically, this is the section of concern: mage-cache-storage-section-invalidation. For example, if you removed the instant-purchase module, there may be some visitors who have the value of {"instant-purchase":true} in localStorage for key mage-cache-storage-section-invalidation
A call to customer/section/load for this endpoint would likely result in a 400 status code as the PHP wasn't written smart enough to check if the index your passing in exists or not. (or maybe that was from a customization we made... I forget)
Regardless, Magento did not expect you to remove their code bloat (like the instant-purchase module and thus they didn't build a method to prevent this pointless hit to the server. Below is my suggestion on how to prevent it however.
Ideally we should delete a removed section from the visitors localStorage. I was moving quick and didn't add that feature... Instead I just removed that section from the list of sections to be called to the server.
In vendor/magento/module-customer/view/frontend/web/js/customer-data.js add this at the top of the reload function. This modifies the list of sections being called in the hit to customer/section/load.
var sectionsToExclude = [ 'instant-purchase' ];
for( var i = 0; i < sectionsToExclude.length; i++ ) {
var indexMessages = sectionNames.indexOf( sectionsToExclude[i] );
if( indexMessages > -1 ) {
sectionNames.splice( indexMessages, 1 );
}
if( sectionNames.length == 0 ) {
break;
}
}
Additional sections can be added to this array if needed.
Also add this logic to vendor/magento/module-customer/view/frontend/web/js/section-config.js
Replace this core line of code: return _.union(_.toArray(actions), _.toArray(sections['*']));
With this logic:
var mergedSectionNames = _.union(_.toArray(actions), _.toArray(sections['*']));
var sectionsToExclude = [ 'instant-purchase' ];
for( var i = 0; i < sectionsToExclude.length; i++ ) {
var indexMessages = mergedSectionNames.indexOf( sectionsToExclude[i] );
if( indexMessages > -1 ) {
mergedSectionNames.splice(indexMessages, 1);
}
if( mergedSectionNames.length == 0 ) {
break;
}
}
if( mergedSectionNames.length > 0 ) {
return mergedSectionNames;
} else {
return false;
}
Of course don't edit core code - make a proper extension of these files and edit them that way. I'm just highlighting what needs to be changed to prevent these errors.
One final comment: the more I've dug into how customer/section/load is implemented the more I hate it's flaws... It prone to too overuse which can impact your server and site performance. This is just one of too many areas I've had to implement. Some of my changes I'm likely to submit to core at some point to try and address fundamental flaws, but finding the time to work through their submission process hasn't been a top priority yet.
One example is that ANY AJAX POST/GET/DELETE request will trigger customer/section/load to be called. But what if that POST request was just to send some tracking data? Nothing changed on the server, so why should we hit it again? Many 3rd party modules make calls like this and they are causing un-necessary hits to customer/section/load (AheadWorks Product Questions and Answers, Mirasvit Rewards, and Facebook Business Module are some at the top of my mind.)
jqXHR. The construct method of the Error class expected the string message (or Object withtoStringmethod).