Summary
Add richer context lifecycle APIs for scoped usage, cancellation-aware execution, and lightweight lifecycle metadata.
Goal
Make the library easier to use in real application code where callers need manual scope control, cancellation propagation, and a clearer view of context lifetime.
Problem
The current API is intentionally small, but the only practical way to interact with context is still centered around the async execution helpers. That is good for simple flows, but it leaves a few common use cases awkward:
- manual scope handling with
using
- cancellation-aware execution paths
- explicit access to previous and current context during a scope
- lightweight lifecycle metadata for diagnostics
Scope
Design Expectations
- The new API should stay thin and predictable.
- Cancellation support should not introduce hidden global state.
- Scope metadata should be useful for diagnostics without becoming full audit system.
- Existing async execution behavior should remain unchanged.
Acceptance Criteria
- The package exposes manual scope based API for context activation.
- The package supports cancellation-token based execution helpers.
- The scope model exposes enough metadata to inspect lifecycle state.
- Existing execution helpers keep working as before.
Non Goals
- No governance layer.
- No persistence backend.
- No event bus or subscriber model.
- No ASP.NET specific integration.
- No policy engine.
Notes
This issue is intended to cover the next useful extension of the core library without moving into larger platform abstraction.
Summary
Add richer context lifecycle APIs for scoped usage, cancellation-aware execution, and lightweight lifecycle metadata.
Goal
Make the library easier to use in real application code where callers need manual scope control, cancellation propagation, and a clearer view of context lifetime.
Problem
The current API is intentionally small, but the only practical way to interact with context is still centered around the async execution helpers. That is good for simple flows, but it leaves a few common use cases awkward:
usingScope
ExecuteInContext(...)overloadsDesign Expectations
Acceptance Criteria
Non Goals
Notes
This issue is intended to cover the next useful extension of the core library without moving into larger platform abstraction.