Often times, the tiny link pointing to an incorrect URL could be the result of a LOG SINK. To demonstrate this, lets take a simple example. Note that this example is very technical in nature and involves diving into the stack trace.
A Shopping Cart application uses a custom logger/exception handler that provides wrapper API like
com.shoppingcart.log.LOG.ERROR
com.shoppingcart.log.LOG.WARN etc
Lets also assume that the application has a common entry point
com.shoppingcart.common.login.doValidate.
Now, lets consider 2 separate log.ERRORs that occur within 2 separate modules within this application.
- Lets assume the first log ERROR occurs in the billing module (com.shoppingcart.billing)
- The second log ERROR occurs in the payment application module (com.shoppingcart.payment)
In this example, since both the modules are different, we expect 2 separate log events and 2 separate tiny link entries. However, since the entry point (Login.doValidate) and error location (log wrapper API) are the same, OverOps will de-duplicate them into the same entry. So, both these issues could point to the same tiny link.
To avoid this - simply add the wrapper class (in this example com.shoppingcart.log.*) to the list of Third Party blacklisted classes. That should solve the problem by changing the error location to the billing and payment modules respectively.
NOTE:
Its very important to note that I tried to oversimplify OverOps de-duplication behavior.
The above example is not 100% accurate description of OverOps de-duplication - there are a few nuances but for purposes of this best practice, this example will suffice.
For more details on this topic, please contact us at support@harness.io.