Skip to content

Update module github.com/oapi-codegen/oapi-codegen/v2 to v2.8.0#253

Open
renovate[bot] wants to merge 1 commit into
masterfrom
renovate/github.com-oapi-codegen-oapi-codegen-v2-2.x
Open

Update module github.com/oapi-codegen/oapi-codegen/v2 to v2.8.0#253
renovate[bot] wants to merge 1 commit into
masterfrom
renovate/github.com-oapi-codegen-oapi-codegen-v2-2.x

Conversation

@renovate

@renovate renovate Bot commented May 1, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Change Age Confidence
github.com/oapi-codegen/oapi-codegen/v2 v2.6.0 → v2.8.0 age confidence

Release Notes

oapi-codegen/oapi-codegen (github.com/oapi-codegen/oapi-codegen/v2)

v2.8.0: : OpenAPI 3.1, fewer assumptions, and a giant bug hunt

Compare Source

OpenAPI 3.1, webhooks, callbacks, and a lot of polish

This is a big one. After a long stretch of internal refactoring across the last couple of releases, we've been able to land some features that have been on the wishlist for years, most notably initial OpenAPI 3.1 support. As always, the full, automatically-generated changelog is at the bottom, and the sections below call out the things you'll actually want to read before upgrading.

When this project was originally released, it supported a narrow set of OpenAPI features, and over time, it has grown from generating code for hand crafted, structurally tight specifications, to very complex, and often messy specifications. I don't think we can ever handle every specification, however, over time, we're going to give users control over as many behaviors as possible, so that our assumptions, which can't be right for everyone, are configurable. More changes of this form will continue to come in the upcoming releases.

Before you upgrade

A couple of housekeeping notes up front:

  • Go 1.25 is now required. If you're not there yet, you'll need to bump your toolchain before pulling this in. We had to update to 1.25 to pull in a kin-openapi that supports OpenAPI 3.1
  • Use generated code with runtime v1.6.0 or newer. Several features in this release (the new Duration type, escaped-path-parameter handling, typed response headers) rely on functionality that landed in the runtime, so make sure you're on github.com/oapi-codegen/runtime v1.6.0+ when you regenerate.

☢️ Breaking changes

We try hard to avoid breaking changes, and when we can't, to make them narrow or configurable.

Trailing-slash routes on the net/http server no longer act as catch-alls (#​2460)

This one only affects the standard-library net/http server (the one built on ServeMux). It's a correctness fix, which is why we decided to just do it rather than hide it behind a flag.

Here's the problem: a ServeMux pattern ending in / matches the entire subtree beneath it, but an OpenAPI path ending in / means exactly that path and nothing deeper. So we were both mismatching the spec's semantics and, worse, panicking at registration time when two such patterns overlapped ambiguously. We now anchor any trailing-slash path with {$} so it matches only what the spec says it should.

The result: if your spec has trailing-slash paths, requests to deeper URLs that used to get swallowed by the catch-all will now correctly return 404. (ServeMux still issues its usual 307 redirect from the un-slashed path to the canonical one.) If you were relying on the old subtree behavior, that was never what your spec actually declared.

Security scopes are no longer emitted by default (#​2440)

Generated servers used to emit per-scheme context key types (bearerAuthContextKey and friends), scope constants (BearerAuthScopes), and per-operation context stores that flattened your spec's security requirements into the request context. We've stopped emitting these by default.

The reason is that this machinery is fundamentally broken: it can't represent alternative (OR), combined (AND), or anonymous ({}) security requirements, so it quietly encourages people to build authorization logic on top of a representation that doesn't actually capture what the spec says. Authentication and authorization belong in the request validation middleware, which evaluates the real security requirements directly.

If you genuinely need the old emission back, there's an opt-in flag:

compatibility:
  enable-auth-scopes-on-context: true

We'd encourage you to migrate to the validation middleware instead, but the flag is there if you need a bridge.

🎉 Notable changes

OpenAPI 3.1 support (#​2336)

Finally, after several years of requests, we've been able to close #​373, adding OpenAPI 3.1 support. We've added support for callbacks and webhooks, and we support several OpenAPI 3.1 idioms, such as flexible enums via oneOf, as well as type: [T, "null"]-style nullability. This is initial support, so we'd love to hear about the specs it doesn't yet handle well.

While oapi-codegen would love to see an increase in sponsorship to make the project more sustainable, if we had to choose, we'd prefer to see that money go upstream to kin-openapi, which is the OpenAPI library that powers us and a large part of the Go ecosystem.

We're working to sponsor Pierre, the solo kin-openapi maintainer, with a significant portion of our own funds, and really hope that y'all consider sponsorship to support the important work that he does.

The OpenAPI 3.1 support in kin-openapi wouldn't have been possible without Pierre's maintainership, and a number of external contributors.

Optionally hoist anonymous schemas into named types (#​2366)

You can now opt in to having every anonymous, inline schema hoisted into a top-level named type, with a name derived from its location (path) in the spec. If you've ever wanted a real, referenceable Go type for some deeply-nested inline object instead of an anonymous struct, this is for you.

We now validate the spec before generating (#​2435)

oapi-codegen has always been extremely permissive about the specs it accepts, which is great until a malformed spec leads to non-compiling generated code and a confusing debugging session. We now run a validation pass over the spec before code generation, which lets us catch a class of errors that are hard to detect during codegen and abort early with a meaningful error message instead of emitting broken Go. As a bonus, this makes us considerably more resilient to malicious or garbage input.

Handlers are now registered in spec order (#​2465, #​2477)

Some routers make matching decisions based on the order in which handlers are registered. To make behavior predictable and match your intent, we now emit route registrations in the same order the paths appear in your spec, so you have control of the order by controlling the order in which you declare them. To go back to the previous behavior, add this to your configuration:

compatibility:
  sort-handler-registrations: true
format: duration now maps to a real Duration type (#​2458)

A type: string, format: duration schema used to fall through to a plain Go string, leaving all the parsing and validation up to you. The runtime now ships an RFC 3339 Duration type (added in runtime v1.5.0), and the default type mapping resolves format: duration to it, right alongside the other formats like date, uuid, email, and binary.

This does change the generated type for specs already using format: duration. If you'd rather keep the old plain-string behavior, map the format back explicitly in your config:

output-options:
  type-mapping:
    string:
      formats:
        duration:
          type: string
The rest of the notables and new features

A quick rundown of the other behavior-affecting changes worth knowing about:

  • Fiber v3 support (#​2431, thanks @​dillonbuchanan-maia-tech) — codegen now targets the stable Fiber v3, in addition to v2.
  • Anonymous security alternatives are allowed (#​2432, thanks @​kriptoburak) — an empty {} entry in a security list (i.e. "auth optional here") is now handled correctly.
  • Response models expose schema-extraction helpers (#​2379, thanks @​rd-andreas-tollkoetter) — added functions on response models to make it easier to pull schemas back out.
  • deprecated Godoc is emitted correctly (#​2405, thanks @​jamietanna) — deprecation markers now land on the right declarations so your tooling actually flags them.
  • Better generated client Godoc (#​2407, thanks @​jamietanna) — improved documentation comments on generated client code.
  • Escaped-path-parameter handling (#​2457) — generated code now tells the runtime whether the router delivers already-escaped path parameter values, fixing a class of decoding bugs (this is part of why you want runtime v1.6.0+).
  • Typed response headers (#​2462, #​2463) — response headers are now parsed into typed fields on the client response wrappers.

There's a great deal more in the way of bug fixes below — this release fixes a large batch of long-standing issues in the aggregate-type (allOf/anyOf/oneOf), discriminator, and external-$ref code paths. Thank you to everyone who reported issues and sent PRs.

☢️ Breaking changes

🎉 Notable changes

🚀 New features and improvements

🐛 Bug fixes

📝 Documentation updates

👻 Maintenance

📦 Dependency updates

33 changes

Sponsors

We would like to thank our sponsors for their support during this release.

DevZero logo

Cybozu logo

We'd also like to thank Greptile for allowing our project to use their code review system.

Greptile logo

v2.7.2: More fixes for code injection issues

Compare Source

String escaping fixes due to more code injection issues

We've had two more code injection issues reported in oapi-codegen, thanks @​Gal3M, @​mrostamipoor for these findings.

These specific issues are now patches in the main branch and in this v2.7.2 release.

You shouldn't blindly trust OpenAPI specs

This code wasn't originally written assuming code generation from random specs from the internet, and it never took any measures to protect itself from malicious specifications, the assumption being that you control your specification, and that you actually look over generated code.

For example, all these RCE exploits rely on using the package init() function in the generated code to run some malicious code at package startup. A way to test for this is to see whether an init() function is emitted, which we currently don't do.

When working with OpenAPI specifications, especially specs you find on remote servers, you should download the spec locally, run some kind of spec validator on it, like openapi-spec-validator, and only then feed it into oapi-codegen. We're very permissive in accepting broken specifications, intentionally, since people feed a lot of garbage input, but this flexibility also makes us weak to these kinds of attacks. There are hundreds of injection sites in oapi-codegen based on my survey.

For the next minor release, v2.8.0, we're going to validate the spec before code generation (#​2435), however, since this introduces a new set of failure modes, I don't want to include it in a maintenance release version. The future release is resilient against many forms of injection, and the spec validation has the added benefit that it can generate meaningful error messages for garbage input, where currently, we generate non-compiling code.

Until then, please do sanity checks on your input specifications, on the generated output, and don't fetch specs from the internet in your build, commit both the spec locally into your source control, and go through code review. In our repo, we've hooked up Greptile to catch issues like this, and you should also use some code quality tool. We can't possibly protect against every kind of attack with simple heuristics.

Sponsors

We would like to thank our sponsors for their support during this release.

DevZero logo

Cybozu logo

We'd also like to thank Greptile for allowing our project to use their code review system.

Greptile logo

v2.7.1: Security fix for Go code injection

Compare Source

This is a security fix for a code injection vulnerability in v2.7.0, please see:

GHSA-rjwr-m7qx-3fjr

[!NOTE]
A vulnerability like this requires that it is missed in code review and that you then call the malicious method.

Using an init() function could be enough to not require a direct call to the code, and instead rely on you importing the package, but either way, code review should be performed before any oapi-codegen generated code is executed.

We strongly recommend all users to be reviewing changes to their generated code before they execute anything within it, to protect against supply chain attacks or malicious injected code.

This is also why we recommend oapi-codegen generated code is committed to source control.

We're more strict about escaping strings passed into the OpenAPI specification, so that people can't inject Go code into generated code.

The problem was that it was possible to craft a description for server URL's which would emit arbitrary Go code, so if an attacker controlled your specification, they could inject Go code into your generated code which could do something malicious.

v2.7.0: : Squashing bugs, many bugs (and adding some features)

Compare Source

Many improvements and even more bug fixes

This v2.7.0 release of oapi-codegen contains quite a bit of internal refactoring, focused on our most historically fragile code paths, which relate to the aggregate types (allOf/anyOf/oneOf), $ref to external specs, enums, and the spec traversal logic missing quite a few leaf nodes where models should have been generated, but were skipped.

The biggest changes are explicitly described in the sections below, and the full list of commits is at the bottom.

Thank you to all contributors, we've been going through all past PR's and updating them and merging where we can, and thanks to all our users for reporting issues that you hit.

I've (@​mromaszewicz) used a lot of LLM help here to scrub through old issues and do some deep internal refactoring to address common problem areas. I intend to continue doing this, since the conditional generation logic is getting quite complicated. When I originally released oapi-codegen, the use case was much simpler, all the models were under #/components/schemas, and all the references to them were in the requests, responses, etc. I never imagine how many things would be external references or unions, and how many complex OpenAPI specifications people would be generating code for. The initial design was never flexible enough to handle that, so ongoing bug fixes are getting increasingly complex due to edge cases. This version has a lot of internal changes you won't see as a user, but the way we handle type generation internally is unifying lots of copy/paste re-implementations into reusable code for consistency. Most of these changes can be done transparently, but some can't, so, onto the changes:

Code generation changes which might require some changes on your end

This release contains three changes, all very narrow in scope, which will require some manual adjustment of your own code. We've decided that these are small enough and uncommon enough not to require opt-in, which causes internal complexity. It's always a judgment call with these. If we got it wrong, we're happy to revisit it in a maintenance release.

Strict-server external response refs require strict-server generation in both packages (#​2357)

If your strict-server spec uses an external $ref to a components/responses/... defined in another spec, that other
spec must also be generated with strict-server: true. Add it to the source spec's config and regenerate:

# config for the spec being $ref'd
generate:
  models: true
  strict-server: true   # now required when imported by a strict-server spec

This restores the v2.0.0 behavior that lets you cast response models across package boundaries — the standard pattern
for sharing error models (e.g. a common 400) across services. PR #​1387 had silently changed the embedded type from N400JSONResponse to the bare externalRef0.N400, so the local and external response structs no longer had
matching types and casts stopped compiling.

Many more anonymous inner schemas are now hoisted into top level schemas

Inline oneOf, anyOf, and additionalProperties schemas embedded directly under an operation's request or response
body now flow through the same boilerplate-emission pipeline as components/schemas, so they get the
As* / From* / Merge* accessor methods they were previously missing. As part of that change, two older naming patterns
are replaced with one pattern, shared with all components:

GetPets_200_Data_Item             →  GetPets200JSONResponseBody_Data_Item
GetPets200JSONResponse_Data_Item  →  GetPets200JSONResponseBody_Data_Item

In practice, we think this shouldn't break anyone, because this change addresses a bug which produced pointless types
with no benefit, and you never interact with these directly, but rather you'd call an accessor on a field of a model.

Strict middleware typedefs are now inlined (#​2271)

StrictHandlerFunc and StrictMiddlewareFunc in generated strict-server code are now inline type definitions instead
of aliases to github.com/oapi-codegen/runtime/strictmiddleware/<framework>. Generated servers no longer import that package.

Before (Echo example):

import strictecho "github.com/oapi-codegen/runtime/strictmiddleware/echo"

type StrictHandlerFunc = strictecho.StrictEchoHandlerFunc
type StrictMiddlewareFunc = strictecho.StrictEchoMiddlewareFunc

After:

type StrictHandlerFunc func(ctx echo.Context, request any) (any, error)
type StrictMiddlewareFunc func(f StrictHandlerFunc, operationID string) StrictHandlerFunc

If your code referenced the per-framework names directly — strictecho.StrictEchoHandlerFunc, strictgin.StrictGinHandlerFunc, strictnethttp.StrictHTTPHandlerFunc, strictiris.StrictIrisHandlerFunc, strictecho5.StrictEcho5HandlerFunc — switch to the local StrictHandlerFunc / StrictMiddlewareFunc exposed by the generated server package, or import runtime/strictmiddleware/<framework> yourself if you really want those names. The underlying signatures are unchanged, so any value satisfying the old type still satisfies the new one.

🎉 Notable changes

Go 1.24 required (#​2264)

oapi-codegen itself now requires Go 1.24.4+ to build and run. The toolchain in your project's go.mod (the one used to invoke the codegen) must be ≥ 1.24.4. The code generated will still likely work on older versions. We had to update to Go 1.24 in order to update some dependencies to address vulnerabilities. Go 1.24 is no longer supported, so our next release will update to Go 1.25,
and the plan is to stay on supported Go versions. I'm not sure if 1.25 will come in v2.8.0 or v2.7.1 yet, but it's imminent. We
have a number of submodules in this repo which exist only to test Go 1.25 routers in a 1.24 module, and it allows us to
simplify.

Unfortunately, some of our transitive dependencies result in a broken build, by default, so you might have to pin these
packages to specific versions:

  • github.com/speakeasy-api/jsonpath v0.6.3
  • github.com/dprotaso/go-yit v0.0.0-20220510233725-9ba8df137936 (See #​2015 for some discusion)
Multi-pass type name resolution (#​2213)

Set output-options.resolve-type-name-collisions: true to make the codegen detect identifier collisions across schemas, parameters, request bodies, response components, and operation-derived types — and resolve them deterministically by suffixing the loser. Specs that previously failed to generate because two definitions wanted the same Go name now succeed.

Trivial example. With this spec:

components:
  schemas:
    Status:
      type: string
      enum: [active, archived]
  parameters:
    Status:
      name: status
      in: query
      schema:
        type: string

output-options.resolve-type-name-collisions: true produces:

type Status string                    // from components.schemas.Status
const StatusActive   Status = "active"
const StatusArchived Status = "archived"

type StatusParameter = string         // from components.parameters.Status

Collision resolution is opt-in. Generated identifier names depend on the current set of collisions in the spec;
adding a new schema or parameter later that collides with an existing one will rename the existing one to break the new collision.
That can silently break user code that imports the previously-stable name as the spec drifts. However, despite the drift,
more specs can now correctly generate boilerplate.

Parameter binding matrix (#​2307)

The OpenAPI parameter style × explode × type matrix is now fully supported and round-trips consistently across
every server backend. Path/query/header/cookie parameters across primitive, array, and object types — including
style: form / spaceDelimited / pipeDelimited / deepObject × explode: true/false, and style: simple for headers —
generate the same binding logic on every server, and the client-side encoding is symmetric. The internal parameter test suite (internal/test/parameters/) now exercises every combination through a server round-trip per backend.

If you previously hit an unsupported style error, or saw a parameter serialization work under one backend but not another,
regenerate and the issue should be gone.

You will need to use version v1.4.0 or higher of github.com/oapi-codegen/runtime.

Optional / nullable response headers (#​2301)

For strict-server responses, optional and nullable headers now generate as pointer fields (or nullable.Nullable[T]
when the nullable-types output option is set). The generated server only calls w.Header().Set(...) when the field
is non-nil, so callers can omit optional headers cleanly.

Spec:

responses:
  '200':
    headers:
      X-Required: { required: true, schema: { type: string } }
      X-Optional: { schema: { type: string } }

Before:

type GetFoo200ResponseHeaders struct {
    XRequired string
    XOptional string  // always emitted, even when empty
}

After:

type GetFoo200ResponseHeaders struct {
    XRequired string
    XOptional *string  // nil → header not sent
}

To opt out of this change, set compatibility.headers-implicitly-required: true to restore the previous always-required behavior. This change breaks enough code that we flagified it.

🚀 New features

Echo v5 server support (#​2188)

Echo v5 (the upcoming major version) is now a supported server framework. Generate with generate.echo5-server: true. Echo v4 is unchanged and remains the target of generate.echo-server.

Per-handler middleware in Fiber (#​2302)

Fiber generated servers now accept a HandlerMiddlewares []HandlerMiddlewareFunc slice in FiberServerOptions, applied around every operation handler. The middleware signature is func(c *fiber.Ctx, next fiber.Handler) error, matching Fiber's native middleware pattern. Useful for cross-cutting concerns (auth, logging, metrics) that should run after path-level routing but inside the generated-handler boundary.

Per-operation middleware in Echo (#​2353)

Echo's RegisterHandlersWithOptions now accepts an OperationMiddlewares map[string][]echo.MiddlewareFunc keyed by operationId, attaching middleware to specific operations at registration time:

api.RegisterHandlersWithOptions(e, server, api.RegisterHandlersOptions{
    OperationMiddlewares: map[string][]echo.MiddlewareFunc{
        "createPet": {authMiddleware, auditMiddleware},
        "deletePet": {authMiddleware, adminOnlyMiddleware},
    },
})

Operations with no entry in the map (or a nil map) are registered with no extra middleware. Available for both Echo v4 and Echo v5 generated servers.

Strict-gin error handlers (#​1600)

The Gin strict server now exposes RequestErrorHandlerFunc and ResponseErrorHandlerFunc on StrictServerOptions, matching the pattern already available for the Echo strict server. Bind errors and response-write errors flow through your custom handler instead of using gin's default abort behaviour. Defaults are preserved if you don't set them.

☢️ Breaking changes

🎉 Notable changes

🚀 New features and improvements

🐛 Bug fixes

✂ Note

PR body was truncated to here.

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate

renovate Bot commented May 1, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

ℹ️ Artifact update notice

File name: go.mod

In order to perform the update(s) described in the table above, Renovate ran the go get command, which resulted in the following additional change(s):

  • 13 additional dependencies were updated

Details:

Package Change
github.com/getkin/kin-openapi v0.133.0 -> v0.142.0
github.com/go-openapi/jsonpointer v0.21.2 -> v0.23.1
github.com/oasdiff/yaml v0.0.0-20250309154309-f31be36b4037 -> v0.1.1
github.com/oasdiff/yaml3 v0.0.0-20250309153720-d2182401db90 -> v0.0.14
github.com/speakeasy-api/jsonpath v0.6.0 -> v0.6.3
golang.org/x/crypto v0.49.0 -> v0.54.0
golang.org/x/mod v0.33.0 -> v0.38.0
golang.org/x/net v0.52.0 -> v0.57.0
golang.org/x/sync v0.20.0 -> v0.22.0
golang.org/x/sys v0.42.0 -> v0.47.0
golang.org/x/term v0.41.0 -> v0.45.0
golang.org/x/text v0.35.0 -> v0.40.0
golang.org/x/tools v0.42.0 -> v0.48.0

@renovate renovate Bot added the dependency label May 1, 2026
@renovate renovate Bot changed the title Update module github.com/oapi-codegen/oapi-codegen/v2 to v2.7.0 Update module github.com/oapi-codegen/oapi-codegen/v2 to v2.7.1 Jun 6, 2026
@renovate
renovate Bot force-pushed the renovate/github.com-oapi-codegen-oapi-codegen-v2-2.x branch from 2388ca3 to 5a14dae Compare June 6, 2026 01:04
@renovate renovate Bot changed the title Update module github.com/oapi-codegen/oapi-codegen/v2 to v2.7.1 Update module github.com/oapi-codegen/oapi-codegen/v2 to v2.7.2 Jul 7, 2026
@renovate
renovate Bot force-pushed the renovate/github.com-oapi-codegen-oapi-codegen-v2-2.x branch from 5a14dae to aa32fd6 Compare July 7, 2026 03:52
@renovate renovate Bot changed the title Update module github.com/oapi-codegen/oapi-codegen/v2 to v2.7.2 Update module github.com/oapi-codegen/oapi-codegen/v2 to v2.7.2 - autoclosed Jul 15, 2026
@renovate renovate Bot closed this Jul 15, 2026
@renovate
renovate Bot deleted the renovate/github.com-oapi-codegen-oapi-codegen-v2-2.x branch July 15, 2026 15:52
@renovate renovate Bot changed the title Update module github.com/oapi-codegen/oapi-codegen/v2 to v2.7.2 - autoclosed Update module github.com/oapi-codegen/oapi-codegen/v2 to v2.7.2 Jul 15, 2026
@renovate renovate Bot reopened this Jul 15, 2026
@renovate
renovate Bot force-pushed the renovate/github.com-oapi-codegen-oapi-codegen-v2-2.x branch 2 times, most recently from aa32fd6 to 1388278 Compare July 15, 2026 19:37
@renovate renovate Bot changed the title Update module github.com/oapi-codegen/oapi-codegen/v2 to v2.7.2 Update module github.com/oapi-codegen/oapi-codegen/v2 to v2.7.2 - autoclosed Jul 16, 2026
@renovate renovate Bot closed this Jul 16, 2026
@renovate renovate Bot changed the title Update module github.com/oapi-codegen/oapi-codegen/v2 to v2.7.2 - autoclosed Update module github.com/oapi-codegen/oapi-codegen/v2 to v2.7.2 Jul 17, 2026
@renovate renovate Bot reopened this Jul 17, 2026
@renovate
renovate Bot force-pushed the renovate/github.com-oapi-codegen-oapi-codegen-v2-2.x branch 2 times, most recently from 1388278 to 9f3fde2 Compare July 17, 2026 10:11
@renovate
renovate Bot force-pushed the renovate/github.com-oapi-codegen-oapi-codegen-v2-2.x branch from 9f3fde2 to 651be58 Compare July 17, 2026 15:16
@renovate renovate Bot changed the title Update module github.com/oapi-codegen/oapi-codegen/v2 to v2.7.2 Update module github.com/oapi-codegen/oapi-codegen/v2 to v2.8.0 Jul 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

dependency

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants