Deferred from PR #10636, whose description flagged it as "a design question worth its own issue" — recording it here so it does not get lost when that PR merges.
Behavior
When Restore-DbaDatabase stops at a marked transaction (-StopMark, with -StopBefore or not) or at -RestoreTime, and the stop point is not in the last log file of the chain, the command still attempts to apply the remaining log files. SQL Server refuses them ("The log in this backup set begins at LSN ..., which is too recent to apply"), so:
- without
-EnableException, a successful stop-at-mark restore ends with warnings about the tail files;
- with
-EnableException, a successful stop-at-mark restore throws on the first tail file — the caller cannot tell success from failure without probing the database afterwards.
The resurrected StopAt tests in PR #10636 work around this by arranging the mark to be reachable without tail files where necessary; the underlying behavior is unchanged there on purpose.
Design question
Should the restore loop end gracefully once the stop point has been reached — i.e. detect that the target (mark, or point in time) has been satisfied and skip the remaining files instead of letting SQL Server refuse them?
Arguments for: a restore that achieved exactly what was asked should not warn or throw. Arguments for caution: detecting "the stop point is reached" requires interpreting the restore result rather than just forwarding files, and a wrong detection would silently drop log files from a restore that should have continued. A middle ground could be to catch specifically the "too recent to apply" refusal after a satisfied stop and downgrade it to a verbose message.
This issue was created by Claude and reviewed by Andreas Jordan.
Deferred from PR #10636, whose description flagged it as "a design question worth its own issue" — recording it here so it does not get lost when that PR merges.
Behavior
When
Restore-DbaDatabasestops at a marked transaction (-StopMark, with-StopBeforeor not) or at-RestoreTime, and the stop point is not in the last log file of the chain, the command still attempts to apply the remaining log files. SQL Server refuses them ("The log in this backup set begins at LSN ..., which is too recent to apply"), so:-EnableException, a successful stop-at-mark restore ends with warnings about the tail files;-EnableException, a successful stop-at-mark restore throws on the first tail file — the caller cannot tell success from failure without probing the database afterwards.The resurrected StopAt tests in PR #10636 work around this by arranging the mark to be reachable without tail files where necessary; the underlying behavior is unchanged there on purpose.
Design question
Should the restore loop end gracefully once the stop point has been reached — i.e. detect that the target (mark, or point in time) has been satisfied and skip the remaining files instead of letting SQL Server refuse them?
Arguments for: a restore that achieved exactly what was asked should not warn or throw. Arguments for caution: detecting "the stop point is reached" requires interpreting the restore result rather than just forwarding files, and a wrong detection would silently drop log files from a restore that should have continued. A middle ground could be to catch specifically the "too recent to apply" refusal after a satisfied stop and downgrade it to a verbose message.
This issue was created by Claude and reviewed by Andreas Jordan.