Content pipeline converts cancellation into failure values

[bobtista]

The content pipeline reports cancellation as a return value rather than an exception at several layers, so callers can't distinguish a cancelled shutdown from a genuine failure.

#357 / #358 fixed this at the two ends — ContentOrchestrator rethrows for the caller's token, and the three profile reconcilers check the token after every orchestrator call. The layers in between were left alone as out of scope for an alpha-4 backport.

Not reachable today — do this with the UI cancellation work, not before

Every current entry point into the pipeline passes CancellationToken.None or omits the token:

Caller	Token
ContentBrowserViewModel.SearchAsync	none
PublisherCardViewModel → AcquireContentAsync	none
PublisherCardViewModel → ProfileContentService	explicit CancellationToken.None (×2)
GameProfileLauncherViewModel → PublisherProfileOrchestrator	none (×4)
ProfileLauncherFacade.LaunchProfileAsync	none (both callers)

ProfileContentService and PublisherProfileOrchestrator do thread tokens down to the orchestrator, but their own callers hand them None. PublisherCardViewModel has a real _cts cancelled on dispose, but it only feeds _profileManager — it never reaches the orchestrator.

The only genuinely cancellable path into the pipeline is the reconcilers on shutdown, which #357/#358 already fixed. So no current code path can produce the state described here.

This matters for sequencing. The expensive part isn't adding rethrows — it's deciding, per awaited dependency, whether a failure observed under a cancelled token is cancellation or a real error. With no reachable scenario, that's a guess. Whoever wires real cancellation into the UI (cancel button on downloads, shutdown propagation through browse/acquire) should do this sweep alongside it, so the semantics are chosen against behaviour that can actually be tested.

Remaining sites

• BaseContentProvider.PrepareContentAsync — bare catch (Exception) converts cancellation to a failed OperationResult
• SuperHackersProvider.PrepareContentInternalAsync — same, and runs before the base class, so fixing only BaseContentProvider changes nothing for this provider
• CommunityOutpostProvider / GeneralsOnlineProvider / GitHubContentProvider / LocalFileSystemContentProvider — same shape
• FileSystemDeliverer, HttpContentDeliverer
• ContentOrchestrator.RemoveContentAsync — off the reconciler path, same pattern
• ContentOrchestrator.AcquireContentAsync / EnsureInstallationPoolPathAsync — dependencies returning a failure value after cancellation are still treated as real errors

One trap worth knowing

Filter on the caller's token. HttpClient timeouts surface as TaskCanceledException, which derives from OperationCanceledException, so an unconditional rethrow lets one slow provider abort an entire aggregate search — this was caught in review on #358 after exactly that mistake. Use catch (OperationCanceledException) when (cancellationToken.IsCancellationRequested).

[coderabbitai]

🔗 Related PRs

#312 - fix: disable unsafe CAS garbage collection [merged]
#332 - feat(launching): launch the native BGFX client against retail archives [merged]
#343 - fix(generalsonline): launch and track through the Easy Anti-Cheat bootstrapper [open]
#349 - fix(cas): fall back from unwritable installation pools [merged]
#357 - fix(content): propagate cancellation from SuperHackers reconciler acquisition [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[coderabbitai]

Coding Plan

Summary

• Apply the established repo idiom catch (OperationCanceledException) when (cancellationToken.IsCancellationRequested) { throw; } before each existing generic catch (Exception) in the provider, deliverer, and orchestrator layers.
• For dependencies that return a failure Result on cancellation instead of throwing (DownloadService, ContentManifestPool, ContentValidator), add a per-call cancellationToken.ThrowIfCancellationRequested() check after a failure result, so cancellation becomes a thrown exception that the new filter propagates.
• Filter strictly on the caller's token so a slow provider timeout (TaskCanceledException not tied to the caller's token) does not abort an aggregate operation.
• Treat the EnsureInstallationPoolPathAsync reference as stale. Apply the fix to the real failure-returning dependency calls inside AcquireContentAsync instead.

Design Choices

Design Choice 1: Distinguishing cancellation-caused failure Result values from real failures

Options Considered:

1. Add an IsCancelled flag to ResultBase and a CreateCancelled() factory, then propagate that flag up through every layer.
2. After an awaited dependency returns a failure result, check cancellationToken.IsCancellationRequested and, if set, call cancellationToken.ThrowIfCancellationRequested() to convert the failure into a thrown OperationCanceledException.

Chosen Option: 2

Rationale: This option matches the existing exception-based propagation contract that #357/#358 established. It avoids a new cross-cutting change to the shared Result model. It keeps the per-call decision local to each site.

Design Choice 2: Handling of the EnsureInstallationPoolPathAsync site named in the ticket

Options Considered:

1. Create the method to match the ticket name.
2. Treat the reference as stale and apply the cancellation-aware handling only to the failure-returning dependency calls that actually exist inside AcquireContentAsync.

Chosen Option: 2

Rationale: The named method does not exist. The correct scope is the real failure-returning dependency calls inside AcquireContentAsync (ResolveManifestAsync, GetValidatedContentAsync, PrepareContentAsync, manifest-pool calls).

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Propagate cancellation in content providers

This phase makes the provider layer rethrow cancellation for the caller's token. The PrepareContentInternalAsync override in each derived provider runs inside the base PrepareContentAsync, and each override has its own bare catch. A fix in only the base class does not help these providers. Update each provider catch and the base catch.

Task 1: Add cancellation rethrow to BaseContentProvider

Make the base template method distinguish cancellation from failure.

• Update GenHub/GenHub/Features/Content/Services/ContentProviders/BaseContentProvider.cs.
• In PrepareContentAsync, add catch (OperationCanceledException) when (cancellationToken.IsCancellationRequested) before the existing generic catch (Exception ex).
• In the new catch, log at information level and throw;.
• Do not catch OperationCanceledException that is not for the caller's token. Let the generic catch continue to convert unrelated failures (including provider timeouts not tied to the caller's token) to CreateFailure.

Task 2: Add cancellation rethrow to the provider overrides

Make each derived PrepareContentInternalAsync rethrow cancellation before its own generic catch.

• Update SuperHackersProvider.cs, CommunityOutpostProvider.cs, GeneralsOnlineProvider.cs, and GitHubContentProvider.cs.
• In each PrepareContentInternalAsync, add catch (OperationCanceledException) when (cancellationToken.IsCancellationRequested) { ...; throw; } before the existing generic catch (Exception ex).
• Keep the generic catch unchanged, so real errors and non-caller-token cancellations still map to CreateFailure.
• These overrides await Deliverer.DeliverContentAsync(...), which returns a failure Result on cancellation. After that call, if !deliveryResult.Success, call cancellationToken.ThrowIfCancellationRequested() before returning CreateFailure, so a cancelled delivery becomes a thrown cancellation caught by the new filter.

Task 3: Add a cancellation check to LocalFileSystemContentProvider

Keep the local provider consistent with the other providers.

• Update LocalFileSystemContentProvider.cs.
• PrepareContentInternalAsync has no async work and no try/catch. Add cancellationToken.ThrowIfCancellationRequested() at the start so a cancelled caller observes cancellation.
• Do not add a try/catch. There is no failure path to convert.

🤖 Prompt for AI agents

Implement cancellation propagation in the content provider layer so that
cancellation is rethrown for the caller's token instead of converted into a
failure result.

1. In
`GenHub/GenHub/Features/Content/Services/ContentProviders/BaseContentProvider.cs`,
in `PrepareContentAsync`, add a `catch (OperationCanceledException) when
(cancellationToken.IsCancellationRequested)` block before the existing generic
`catch (Exception ex)`. In this new catch block, log at information level, then
`throw;`. Do not catch `OperationCanceledException` instances that are not tied
to the caller's token; leave the generic catch to convert those (including
provider timeouts unrelated to the caller's token) to `CreateFailure`.

2. In `SuperHackersProvider.cs`, `CommunityOutpostProvider.cs`,
`GeneralsOnlineProvider.cs`, and `GitHubContentProvider.cs`, in each
`PrepareContentInternalAsync`, add the same `catch (OperationCanceledException)
when (cancellationToken.IsCancellationRequested) { ...; throw; }` block before
the existing generic `catch (Exception ex)`. Keep the generic catch unchanged.
In each of these overrides, after the call to
`Deliverer.DeliverContentAsync(...)`, check `!deliveryResult.Success`; if true,
call `cancellationToken.ThrowIfCancellationRequested()` before returning
`CreateFailure`, so a cancelled delivery becomes a thrown cancellation that the
new catch filter propagates.

3. In `LocalFileSystemContentProvider.cs`, add
`cancellationToken.ThrowIfCancellationRequested()` at the start of
`PrepareContentInternalAsync`. Do not add a try/catch block here, since this
method has no async work and no failure path to convert.

Phase 2: Propagate cancellation in deliverers

This phase makes the delivery layer rethrow cancellation. HttpContentDeliverer uses DownloadService, which swallows cancellation into a failed DownloadResult. The deliverer therefore observes a failure result, not an exception. Both a rethrow filter and a per-call decision are needed.

Task 1: Add cancellation rethrow to FileSystemDeliverer

Make file delivery rethrow cancellation for the caller's token.

• Update GenHub/GenHub/Features/Content/Services/ContentDeliverers/FileSystemDeliverer.cs.
• In DeliverContentAsync, add catch (OperationCanceledException) when (cancellationToken.IsCancellationRequested) { ...; throw; } before the generic catch (Exception ex).
• The method already calls cancellationToken.ThrowIfCancellationRequested() in its file loop. The new filter now propagates that cancellation instead of converting it to a failure.

Task 2: Add cancellation rethrow and per-call decision to HttpContentDeliverer

Make HTTP delivery distinguish a cancelled download from a real download failure.

• Update GenHub/GenHub/Features/Content/Services/ContentDeliverers/HttpContentDeliverer.cs.
• Add the catch (OperationCanceledException) when (cancellationToken.IsCancellationRequested) { ...; throw; } filter before the generic catch (Exception ex).
• DownloadService.DownloadFileAsync returns a failed DownloadResult on cancellation instead of throwing. After the download call, when !downloadResult.Success, call cancellationToken.ThrowIfCancellationRequested() before returning CreateFailure, so a cancelled download becomes a thrown cancellation caught by the new filter.

🤖 Prompt for AI agents

Implement cancellation propagation in the delivery layer so that cancellation is
rethrown for the caller's token instead of converted into a failure result.

1. In
`GenHub/GenHub/Features/Content/Services/ContentDeliverers/FileSystemDeliverer.cs`,
in `DeliverContentAsync`, add a `catch (OperationCanceledException) when
(cancellationToken.IsCancellationRequested) { ...; throw; }` block before the
existing generic `catch (Exception ex)`. The method already calls
`cancellationToken.ThrowIfCancellationRequested()` in its file loop; with the
new filter in place, this cancellation now propagates instead of being converted
to a failure.

2. In
`GenHub/GenHub/Features/Content/Services/ContentDeliverers/HttpContentDeliverer.cs`,
add the same `catch (OperationCanceledException) when
(cancellationToken.IsCancellationRequested) { ...; throw; }` filter before the
generic `catch (Exception ex)`. After the call to
`DownloadService.DownloadFileAsync`, check `!downloadResult.Success`; if true,
call `cancellationToken.ThrowIfCancellationRequested()` before returning
`CreateFailure`. This is required because `DownloadFileAsync` returns a failed
`DownloadResult` on cancellation instead of throwing, so this per-call check
converts a cancelled download into a thrown cancellation that the new catch
filter propagates.

Phase 3: Propagate cancellation in ContentOrchestrator direct callers

This phase covers the orchestrator methods that are off the reconciler path. AcquireContentAsync and RemoveAcquiredContentAsync both use a bare catch. Several awaited dependencies return failure Result values on cancellation instead of throwing, so each such call needs a per-call decision.

Task 1: Add cancellation rethrow and per-call decisions to AcquireContentAsync

Make content acquisition rethrow cancellation and treat failure-under-cancellation as cancellation.

• Update GenHub/GenHub/Features/Content/Services/ContentOrchestrator.cs.
• In AcquireContentAsync, add catch (OperationCanceledException) when (cancellationToken.IsCancellationRequested) { ...; throw; } before the outer generic catch (Exception ex).
• Apply a per-call decision to each awaited dependency that returns a failure value on cancellation: ResolveManifestAsync, provider.GetValidatedContentAsync, provider.PrepareContentAsync, _manifestPool.IsManifestAcquiredAsync, and _manifestPool.AddManifestAsync. When any of these returns a failure result, call cancellationToken.ThrowIfCancellationRequested() before returning CreateFailure.
• For _contentValidator.ValidateManifestAsync and _contentValidator.ValidateAllAsync, apply the same ThrowIfCancellationRequested() check when they return an invalid result, because the validator can return an Error-severity result whose message is the cancellation message.
• Do not resolve any CAS or installation-pool path here. No such logic exists in this method. The EnsureInstallationPoolPathAsync reference in the ticket does not match any code.

Task 2: Add cancellation rethrow and per-call decision to RemoveAcquiredContentAsync

Make content removal rethrow cancellation and honor the removal failure flag.

• Update RemoveAcquiredContentAsync in GenHub/GenHub/Features/Content/Services/ContentOrchestrator.cs. This is the method the ticket refers to as RemoveContentAsync. The literal RemoveContentAsync name belongs to ContentStorageService and is not the orchestrator method named in the ticket.
• Add catch (OperationCanceledException) when (cancellationToken.IsCancellationRequested) { ...; throw; } before the generic catch (Exception ex).
• _manifestPool.RemoveManifestAsync returns a failure Result on cancellation instead of throwing. The current code does not check its Success flag. Add a check: when it returns a failure result, call cancellationToken.ThrowIfCancellationRequested(), then return CreateFailure for a real failure.
• _cache.InvalidateAsync ignores the token and never fails. No change is needed for that call.

🤖 Prompt for AI agents

Implement cancellation propagation in the `ContentOrchestrator` methods that are
off the reconciler path: `AcquireContentAsync` and `RemoveAcquiredContentAsync`.
Both currently use a bare generic catch, and several awaited dependencies return
failure `Result` values on cancellation instead of throwing.

1. In `AcquireContentAsync`, add `catch (OperationCanceledException) when
(cancellationToken.IsCancellationRequested) { ...; throw; }` before the outer
generic `catch (Exception ex)`. For each of the following awaited dependency
calls, when the call returns a failure result, call
`cancellationToken.ThrowIfCancellationRequested()` before returning
`CreateFailure`: `ResolveManifestAsync`, `provider.GetValidatedContentAsync`,
`provider.PrepareContentAsync`, `_manifestPool.IsManifestAcquiredAsync`, and
`_manifestPool.AddManifestAsync`. Apply the same
`ThrowIfCancellationRequested()` check to
`_contentValidator.ValidateManifestAsync` and
`_contentValidator.ValidateAllAsync` when they return an invalid result, since
the validator can return an Error-severity result whose message is the
cancellation message. Do not add any CAS or installation-pool path resolution
logic; no such logic exists in this method, and the
`EnsureInstallationPoolPathAsync` reference in the ticket does not correspond to
any existing code.

2. In `RemoveAcquiredContentAsync` (the orchestrator method the ticket refers to
as `RemoveContentAsync`; do not confuse this with the `RemoveContentAsync`
method on `ContentStorageService`), add `catch (OperationCanceledException) when
(cancellationToken.IsCancellationRequested) { ...; throw; }` before the generic
`catch (Exception ex)`. Add a check on the result of
`_manifestPool.RemoveManifestAsync`, which currently is not checked for its
`Success` flag: when it returns a failure result, call
`cancellationToken.ThrowIfCancellationRequested()`, then return `CreateFailure`
for a real failure. Leave `_cache.InvalidateAsync` unchanged, since it ignores
the token and never fails.

Research

The content acquisition pipeline runs in three layers. ContentOrchestrator (GenHub/GenHub/Features/Content/Services/ContentOrchestrator.cs) coordinates search, resolve, acquire, and remove operations. Content providers derive from BaseContentProvider (GenHub/GenHub/Features/Content/Services/ContentProviders/), which uses a template-method pattern: the public PrepareContentAsync wraps an abstract PrepareContentInternalAsync that each provider overrides. Deliverers (GenHub/GenHub/Features/Content/Services/ContentDeliverers/) do file copy and HTTP download work, and use DownloadService (GenHub/GenHub/Common/Services/DownloadService.cs).

Every layer currently wraps its body in a bare catch (Exception ex) that returns OperationResult<T>.CreateFailure(...). OperationCanceledException derives from Exception. Because of this, cancellation is swallowed and converted to a failure result. In addition, DownloadService and ContentManifestPool catch cancellation internally and return a failure Result value instead of throwing. Because of this, upstream callers observe a failed result, not an exception.

The Result model (GenHub/GenHub.Core/Models/Results/) has Success, Failed, Errors, and FirstError, but no cancellation flag. The established repo idiom for correct propagation is an explicit catch (OperationCanceledException) when (cancellationToken.IsCancellationRequested) { throw; } placed before the generic catch (Exception). Examples exist in GameProcessManager.cs, ProfileContentService.cs, and the workspace strategies. No shared helper exists for this pattern.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement cancellation propagation in the content provider layer so that
cancellation is rethrown for the caller's token instead of converted into a
failure result.

1. In
`GenHub/GenHub/Features/Content/Services/ContentProviders/BaseContentProvider.cs`,
in `PrepareContentAsync`, add a `catch (OperationCanceledException) when
(cancellationToken.IsCancellationRequested)` block before the existing generic
`catch (Exception ex)`. In this new catch block, log at information level, then
`throw;`. Do not catch `OperationCanceledException` instances that are not tied
to the caller's token; leave the generic catch to convert those (including
provider timeouts unrelated to the caller's token) to `CreateFailure`.

2. In `SuperHackersProvider.cs`, `CommunityOutpostProvider.cs`,
`GeneralsOnlineProvider.cs`, and `GitHubContentProvider.cs`, in each
`PrepareContentInternalAsync`, add the same `catch (OperationCanceledException)
when (cancellationToken.IsCancellationRequested) { ...; throw; }` block before
the existing generic `catch (Exception ex)`. Keep the generic catch unchanged.
In each of these overrides, after the call to
`Deliverer.DeliverContentAsync(...)`, check `!deliveryResult.Success`; if true,
call `cancellationToken.ThrowIfCancellationRequested()` before returning
`CreateFailure`, so a cancelled delivery becomes a thrown cancellation that the
new catch filter propagates.

3. In `LocalFileSystemContentProvider.cs`, add
`cancellationToken.ThrowIfCancellationRequested()` at the start of
`PrepareContentInternalAsync`. Do not add a try/catch block here, since this
method has no async work and no failure path to convert.
===============================================================================

Task: 2

Implement cancellation propagation in the delivery layer so that cancellation is
rethrown for the caller's token instead of converted into a failure result.

1. In
`GenHub/GenHub/Features/Content/Services/ContentDeliverers/FileSystemDeliverer.cs`,
in `DeliverContentAsync`, add a `catch (OperationCanceledException) when
(cancellationToken.IsCancellationRequested) { ...; throw; }` block before the
existing generic `catch (Exception ex)`. The method already calls
`cancellationToken.ThrowIfCancellationRequested()` in its file loop; with the
new filter in place, this cancellation now propagates instead of being converted
to a failure.

2. In
`GenHub/GenHub/Features/Content/Services/ContentDeliverers/HttpContentDeliverer.cs`,
add the same `catch (OperationCanceledException) when
(cancellationToken.IsCancellationRequested) { ...; throw; }` filter before the
generic `catch (Exception ex)`. After the call to
`DownloadService.DownloadFileAsync`, check `!downloadResult.Success`; if true,
call `cancellationToken.ThrowIfCancellationRequested()` before returning
`CreateFailure`. This is required because `DownloadFileAsync` returns a failed
`DownloadResult` on cancellation instead of throwing, so this per-call check
converts a cancelled download into a thrown cancellation that the new catch
filter propagates.
===============================================================================

Task: 3

Implement cancellation propagation in the `ContentOrchestrator` methods that are
off the reconciler path: `AcquireContentAsync` and `RemoveAcquiredContentAsync`.
Both currently use a bare generic catch, and several awaited dependencies return
failure `Result` values on cancellation instead of throwing.

1. In `AcquireContentAsync`, add `catch (OperationCanceledException) when
(cancellationToken.IsCancellationRequested) { ...; throw; }` before the outer
generic `catch (Exception ex)`. For each of the following awaited dependency
calls, when the call returns a failure result, call
`cancellationToken.ThrowIfCancellationRequested()` before returning
`CreateFailure`: `ResolveManifestAsync`, `provider.GetValidatedContentAsync`,
`provider.PrepareContentAsync`, `_manifestPool.IsManifestAcquiredAsync`, and
`_manifestPool.AddManifestAsync`. Apply the same
`ThrowIfCancellationRequested()` check to
`_contentValidator.ValidateManifestAsync` and
`_contentValidator.ValidateAllAsync` when they return an invalid result, since
the validator can return an Error-severity result whose message is the
cancellation message. Do not add any CAS or installation-pool path resolution
logic; no such logic exists in this method, and the
`EnsureInstallationPoolPathAsync` reference in the ticket does not correspond to
any existing code.

2. In `RemoveAcquiredContentAsync` (the orchestrator method the ticket refers to
as `RemoveContentAsync`; do not confuse this with the `RemoveContentAsync`
method on `ContentStorageService`), add `catch (OperationCanceledException) when
(cancellationToken.IsCancellationRequested) { ...; throw; }` before the generic
`catch (Exception ex)`. Add a check on the result of
`_manifestPool.RemoveManifestAsync`, which currently is not checked for its
`Success` flag: when it returns a failure result, call
`cancellationToken.ThrowIfCancellationRequested()`, then return `CreateFailure`
for a real failure. Leave `_cache.InvalidateAsync` unchanged, since it ignores
the token and never fails.

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!