Skip to content

Bump JasperFx 2.3.0: fix HTTP codegen-write service location (GH-2991) - #2993

Merged
jeremydmiller merged 2 commits into
mainfrom
fix-2991-http-codegen-serviceprovider
May 31, 2026
Merged

jeremydmiller merged 2 commits into
mainfrom
fix-2991-http-codegen-serviceprovider

Conversation

@jeremydmiller

Copy link
Copy Markdown
Member

Closes #2991. Supersedes #2992 (carries its reproduction, with @PerChr's authorship preserved).

Problem

With WolverineHttpOptions.ServiceProviderSource = FromHttpContextRequestServices, the runtime generated correct code (service-located deps from httpContext.RequestServices), but dotnet run -- codegen write generated different and wrong code: an opaque scoped lambda-factory dependency was service-located from an isolated serviceScope while a sibling DbContext used httpContext.RequestServices → two different scoped instances for one logical request.

Root cause + fix (JasperFx)

The CLI codegen paths (DynamicCodeBuilder) never applied the per-file TryReplaceServiceProvider/ReplaceServiceProvider step that the runtime DynamicTypeLoader does. Fixed in jasperfx#401 → JasperFx 2.3.0, including a new IServiceVariableSource.ResetServiceProvider() so the override is isolated per file on the CLI's shared source (otherwise it would leak httpContext.RequestServices into every following file). That PR carries the precise DynamicCodeBuilder regression test.

This PR

  • Bumps JasperFx 2.2.7 → 2.3.0 (consumes the fix).
  • Carries the Reproduction for "HTTP endpoints resolves services wrong in codegen, but works in tests" #2992 reproduction (EfCoreEndpoints /ef/servicelocation + http_handler_with_http_context_sourced_gets_the_same_service). Note: that test exercises the runtime path, which was always correct, so it passes pre- and post-fix — it documents the scenario and guards against a runtime regression; the codegen-write defect itself is guarded by the JasperFx test.

Verification

  • Manually confirmed against this repro: regenerating WolverineWebApi with 2.3.0 via codegen write now resolves the opaque scoped service and the DbContext both from httpContext.RequestServices, with no leak of httpContext.RequestServices into non-HTTP MessageHandler files.
  • using_efcore suite green on 2.3.0.

This bump changes codegen write/preview output for any consumer using a ServiceProviderSource override, so the full Wolverine CI here is the regression net — please watch it.

🤖 Generated with Claude Code

PerfectlyNormal and others added 2 commits May 31, 2026 07:38
…on (GH-2991)

JasperFx 2.3.0 (#401) makes the `codegen write` / preview path honor
WolverineHttpOptions.ServiceProviderSource, matching the runtime. Previously a
service-located dependency (an opaque scoped lambda factory) was generated against an
isolated serviceScope under `codegen write` even when the app configured
FromHttpContextRequestServices, so the pre-generated code differed from (and was wrong
vs.) the runtime-generated code — yielding two different scoped instances for one request.

Carries the reproduction from #2992 (EfCoreEndpoints /ef/servicelocation +
http_handler_with_http_context_sourced_gets_the_same_service). That test exercises the
runtime path (which was always correct); the codegen-write regression itself is guarded by
the new DynamicCodeBuilder test in #401.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@jeremydmiller
jeremydmiller merged commit e278b21 into main May 31, 2026
24 checks passed
This was referenced Jun 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

HTTP endpoints resolves services wrong in codegen, but works in tests

2 participants