You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently if a row fails to be processed 5 times it will be ignored for all future attempts. Logging in #1103 is being added to tell when this happens, but it would be even better to have some way of knowing exactly what rows were ignored (we can't log that information since it contains customer content).
The lease table contains this information (row keys and attempt count), but currently this is cleared once we update the last sync version in the BuildUpdateTablesPostInvocation method.
This is done so that while that version of the row is ignored forever, we will still try to process further changes in the row (in case whatever issue that caused the original failures was fixed).
But doing this means it's difficult to know what rows cause problems and easily track/reprocess those rows. Keeping a historical record of rows that failed to be processed can be hugely beneficial for auditing purposes - similar to the Dead letter queue that the service bus binding implements.
The text was updated successfully, but these errors were encountered:
Branch with work I started to simply not cleanup the leases table, but then found out that we still need to do that or we'll ignore the row forever - even if a new change comes in (which potentially could fix the issue).
Currently if a row fails to be processed 5 times it will be ignored for all future attempts. Logging in #1103 is being added to tell when this happens, but it would be even better to have some way of knowing exactly what rows were ignored (we can't log that information since it contains customer content).
The lease table contains this information (row keys and attempt count), but currently this is cleared once we update the last sync version in the BuildUpdateTablesPostInvocation method.
This is done so that while that version of the row is ignored forever, we will still try to process further changes in the row (in case whatever issue that caused the original failures was fixed).
But doing this means it's difficult to know what rows cause problems and easily track/reprocess those rows. Keeping a historical record of rows that failed to be processed can be hugely beneficial for auditing purposes - similar to the Dead letter queue that the service bus binding implements.
The text was updated successfully, but these errors were encountered: