This looks to be already reported and fixed bug in the product . Fixed in versions 8981 and above.
The problem here is that the tracking workflow is trying to update a tacking entry for a recipient who might have clicked on a link after the broadLogs are purged for the delivery (say after 6 months ) . The tracking workflow tries to insert this record in the trackingLogRcp table and fails as it does not find a corresponding delivery Log.
What I can think of as a remediation step is to look into the tracking log files (0X0000000 log files) present in the app server under var/redir/logs directory and search for the hex value of 1390003 prefixed with h (h1535b3) .
It should give you the tracking log entry the tracking workflow is trying to read. You can delete that line and save the logs and restart tracking workflow after that. Be sure to stop the tracking workflow when making the change and restart the trackingLogd service after deleting the line and then start the tracking workflow.
Alternately , the same tracking log line would also have the delivery ID in hex format . Convert that into decimal and look for the delivery ID in the delivery table. Probably someone deleted the delivery while being active and it caused the problem.
If the delivery is deleted , you need to delete all the lines corresponding to that delivery from the tracking log files else the first solution should be good enough.
But as the instance is on-premise, i'm thinking it's better to have Adobe techOps to delete the delivery on the mid-sourcing instance.The when the tracking wkf will run, it will not try to update the delete deliveries.