Sometime we always have "errors" from third-party scripts which can be embedded via tag manager or under some network conditions of clients and we can't fix or need to wait for long time so we should have an ability to dismiss the issue from the overview page to keep attention on real issues

Many times we may get invalid errors, I can list a few popular cases which we want to exclude

1. Our website use a loader to load different JS in background when they are getting used. However sometime user may navigate to a new page or while these JS were loading which will cause natural errors in console which will be sent to the reporting, this is not helpful.

Since this may happen on any URL so I can't ignore one by one, it would be great if we can ignore it by certain error name or something
2. Many times user come to the pages and navigate very fast between pages which will cause some invalid errors which have " Seconds since page load " very small (just 0.2-0.3 seconds)
3. Also bot traffic comes the website and some third-party JS will get blocked or cause some errors which are not important so we may want to ignore errors from certain user agent,.....

Related to #1
I'm not sure if the extension have handled duplicated error log from same browser, same URL but look like not.
For example for same user they might try to refresh a page many times if they get something wrong so we should prevent saving same issue over and over.
Maybe we should just save one record with last happened time

In order to achieve this, I think we should generate a hash for all information and store it in client storage so we wont send it again.
Or we could process this on server side and just update the last happened time.

What do you think @fredden @sprankhub?

In some cases, there could be many JS errors on same page (either same repeat error or different error) which trigger calling API for recording logs continuously (in my case, there were some JS which had an error but the JS error were fired continuously for a while and the browser was going to hang)

So to make it safe, I think we should make a "stop" for such cases, we shouldn't send more than X errors when user is still on same page.

whilst it is not enforced in the XML and all other aspects of the Web API will continue to work Magento expects the class defined in the webapi service to be an interface that is then preferenced by a class implementing this. This is apparent in \Magento\Webapi\Model\ServiceMetadata::getServiceName specifically on line 215 where it defines the regex pattern to match class names.

as i mentioned the rest of the API will continue to work if you were to reference the services directly, however this does break the schema generation when attempting to query /rest/all/schema?services=all with the error Notice: Undefined offset: 4 in /var/www/html/vendor/magento/module-webapi/Model/ServiceMetadata.php on line 224

this could be resolved from the Magento side with an isset however i could imagine a valid response being that they have set a precedence with the existing webapi implementation that should be followed.

We had this case happening

Should we handle this somehow? Because it is equal as a JS error

Reference https://stackoverflow.com/questions/42306812/jquery-deferred-exceptionhook-shows-warnings-instead-of-errors-in-the-console

Feature Ideas:

User Agent mapping, this could be linked into filtering e.g. being able to easily filter errors seen on iPhones

What an awesome idea! Thanks for this extension :)

Did you check the performance impact of this? Stuff, which comes to my mind:

1. Does this impact the Lighthouse score?
2. Does this impact the Core Web Vitals?
3. Does this also track errors related to ad blockers? This would be bad, because this could then easily lead to tens of AJAX requests...