Assuming you have setup a retention rule for your Backup Management groups of max 28 days and you see snapshots which are older than 28 days,
In general what tends to break SnapManager applications is the volume option 'autodelete' which deletes the snapshots in ontap without notifying SnapManager about that, which in turn will cause the whole SnapManager backup set to be incomplete. When SMSQL then looks for older snapshots to delete and cannot find one of the snapshots in the backup set, it will exit in order to preserve the potentially needed remainings of the backup set. (think about accidental deletions when in fact you need either the database snapshot or the log snapshot).
So, what I would do is check that option and disable it in case is enabled (if you are worried about space, enable autogrow rather than autodelete). Autogrow is safer but you need more space in the aggregate.
a clean up in SMSQL is needed by using the delete backup wizard as shown in the attachment.
SMSQL is responsible for maintaining the proper retention of the SnapInfo folder. You said you noticed the issue when customers upgraded from SMSP 8.0 to 8.1P1. SMSP generates the powershell command that SMSQL then runs so that would be something to check in the new-backup log of the job.
Opening a NetApp support case is the right idea as logs will need to be analyzed.
Manual cleanup can be done on the SnapInfo drive on the SQL server. Delete all the metadata directories for backups older than the retention (watch out for different retention policies like daily and weekly). Also delete all the transaction log backups older than your retention settings for every database. Next you have to check if the there are snapshots of the SnapInfo LUN that are older than your retention and also delete them.
This can be a lot of work that has to be repeated every few weeks. A better solution may be to schedule an extra SMSQL job to make a normal SQL backup (and set the retentions the same as in SMSP) because this job will then clean up the transaction logs and snapshots SMSP isn't cleaning up. Yes, this is an extra backup of your SQL databases, but as there are no extra transaction logs to backup, this will be a fairly fast backup if you schedule it a few hours after your SMSP backup. We will only use this job for maintenance cleanup.
In the meantime there is still no progress in the Support cases. The cases are assigned to development now. If you have the same issue, please create a Netapp support case to create more visibility on this bug.