Add type provider integration tests for CancellationToken-overloaded methods#338
Conversation
Co-authored-by: sergey-tihon <1197905+sergey-tihon@users.noreply.github.com> Agent-Logs-Url: https://github.com/fsprojects/SwaggerProvider/sessions/8363d577-d359-47b3-ae35-5f9003978db0
|
Just as a heads up, I was blocked by some firewall rules while working on your feedback. Expand below for details. Warning Firewall rules blocked me from connecting to one or more addresses (expand for details)I tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
|
@copilot ci still failing |
… invalid IL for structs Co-authored-by: sergey-tihon <1197905+sergey-tihon@users.noreply.github.com> Agent-Logs-Url: https://github.com/fsprojects/SwaggerProvider/sessions/cd02aac9-3f51-40c9-af2f-11d1eda31d77
Fixed in e74b3e2. Root cause: Fix: extract the CT argument by position (always the last parameter in the overload) and use Warning Firewall rules blocked me from connecting to one or more addresses (expand for details)I tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
There was a problem hiding this comment.
Pull request overview
Adds end-to-end integration coverage for type-provider-generated CancellationToken overloads against the existing Swashbuckle test server, and updates the v3 operation invocation compiler to reliably extract the CT argument.
Changes:
- Add new v3 integration tests that call TP-generated methods with explicit
CancellationTokenarguments (including pre-cancelled token behavior). - Register the new test module in the provider test project with correct compile ordering.
- Adjust v3
OperationCompilerto extractCancellationTokenby argument position (last argument) instead of by name.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| tests/SwaggerProvider.ProviderTests/v3/Swashbuckle.CancellationToken.Tests.fs | New integration tests exercising CT overloads (GET/POST, active token, pre-cancelled token). |
| tests/SwaggerProvider.ProviderTests/SwaggerProvider.ProviderTests.fsproj | Includes the new test file after Swashbuckle.ReturnControllers.Tests.fs to reuse api. |
| src/SwaggerProvider.DesignTime/v3/OperationCompiler.fs | Changes CT extraction in provided method invoke code to be position-based and avoid prior name/cast issues. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // When the CancellationToken overload is generated, CancellationToken is always appended last. | ||
| // Extract it by position to avoid name-collision issues and invalid Expr.Coerce | ||
| // on a struct type (which generates an invalid castclass IL instruction). | ||
| let apiArgs, ct = | ||
| let allArgs = List.tail args // skip `this` | ||
|
|
||
| if includeCancellationToken then | ||
| match List.rev allArgs with | ||
| | ctArg :: revApiArgs -> List.rev revApiArgs, Expr.Cast<Threading.CancellationToken>(ctArg) | ||
| | [] -> failwith "Expected CancellationToken argument but argument list was empty" | ||
| else | ||
| allArgs, <@ Threading.CancellationToken.None @> |
There was a problem hiding this comment.
The PR title/description focuses on adding integration tests, but this hunk also changes type provider code generation behavior (CancellationToken argument extraction). Please update the PR description/title to reflect the compiler change (or split into a separate PR) so reviewers don’t miss the functional impact.
| if includeCancellationToken then | ||
| match List.rev allArgs with | ||
| | ctArg :: revApiArgs -> List.rev revApiArgs, Expr.Cast<Threading.CancellationToken>(ctArg) | ||
| | [] -> failwith "Expected CancellationToken argument but argument list was empty" |
There was a problem hiding this comment.
This failwith message is likely only hit when TP invocation arguments are unexpected, but it would be much easier to diagnose if it included the operation/method name (e.g., providedMethodName) and the received argument count. Consider switching to failwithf with that context.
| | [] -> failwith "Expected CancellationToken argument but argument list was empty" | |
| | [] -> | |
| failwithf | |
| "Method '%s' expected a CancellationToken argument as the last parameter but received %d argument(s)." | |
| providedMethodName | |
| allArgs.Length |
b2f0d80
into
repo-assist/feat-cancellationtoken-issue-212-2026-03-23-448c1cde90ec7d95
The CancellationToken PR lacked integration tests that exercise the TP-generated CT overloads end-to-end against a real HTTP server.
Changes
v3/Swashbuckle.CancellationToken.Tests.fs— new test module with 4[<Fact>]tests calling TP-generated methods with explicit CT arguments:CancellationToken.Noneon GET and POST operationsCancellationTokenSourcetoken (happy path)OperationCanceledExceptionSwaggerProvider.ProviderTests.fsproj— includes the new file, ordered afterSwashbuckle.ReturnControllers.Tests.fs(which defines theapiinstance these tests reuse)✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.