Repository navigation
SPSUpdate: retry transient SideBySide update conflicts (6x/15s) - #80
Merged
Merged
Conversation
Retry transient SPWebService.Update() conflicts in Set-SPSSideBySideToken (6 attempts, 15 seconds between attempts), while still failing fast on non-conflict exceptions and surfacing persistent conflicts after the budget. Add Pester coverage for success-after-retry, max-attempts failure, and non-conflict no-retry behavior. Fixes #79 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Pester Test Results 1 files 50 suites 10s ⏱️ Results for commit 93687f5. ♻️ This comment has been updated with latest results. |
There was a problem hiding this comment.
🟡 Changes recommended
Retrying the same stale service instance can exhaust the retry budget without resolving the version conflict.
1 open issue
What changed in this PR
Adds bounded retries for SharePoint side-by-side update conflicts, addressing #79.
Changes:
- Applies six-attempt, 15-second conflict retries to enable, token-setting, and disable operations.
- Adds retry behavior tests and documents the change.
| File | Description |
|---|---|
| tests/Set-SPSSideBySideToken.Tests.ps1 | Tests transient recovery, retry exhaustion, and non-conflict failure. |
| src/Modules/SPSUpdate.Common/Public/Set-SPSSideBySideToken.ps1 | Adds shared conflict-retry logic to all three updates. |
| CHANGELOG.md | Documents the retry policy and user impact. |
Review effort: Balanced
On each retry attempt, reload the current SPWebApplication by identity, reapply the intended change, then call Update() on the refreshed WebService instance. This avoids exhausting retries on a stale object version after PSCONFIG writes. Extend tests with a stale-instance scenario that only succeeds after refresh. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Expand Set-SPSSideBySideToken tests to cover both mode-transition callbacks (enable and disable), each with transient conflict recovery, retry exhaustion, and non-conflict fail-fast behavior. Also keep stale-instance refresh coverage explicit for conflict retries. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
luigilink
commented
Oct 21, 2026
luigilink
left a comment
luigilink
left a comment
Owner
Author
There was a problem hiding this comment.
Files reviewed - LGTM
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull Request (PR) description
Implements a bounded retry policy for transient SharePoint update conflicts in
Set-SPSSideBySideToken.Context: customer runs hit
SPWebService.Update()conflicts whilePSCONFIGwas still writing:Previously the first conflict aborted the side-by-side phase (
Failed to Run Set-SPSSideBySideToken CmdLet).What changed
SPWebService.Update()call inSet-SPSSideBySideToken:[Unreleased]entry.Why this shape
PSCONFIG/ config DB write overlap) without masking real errors.This Pull Request (PR) fixes the following issues
Task list
file CHANGELOG.md. Entry should say what was changed and how that
affects users (if applicable), and reference the issue being resolved
(if applicable).