Per AJV's issues and documentation, a significant change was made between v6->v7 where it is expected for consumers to only call compile once. A potential solution would be to evaluate this.validate(method, match.path) as part of the initialization of the middleware, for each path, and cache the result once. Or, lazily initialize the cache on the first invocation. It sounds like they intend for this cache to be available to the application globally. This way in the middleware it's just retrieving the outcome from the cache rather than recompiling the schemas on every request, thus causing the memory leak.
The code path implicated in the memory leak is this usage of this.validate inside the middleware that is returned by match, because this.validate internally is calling ajv's compile. https://github.com/Hilzu/express-openapi-validate/blob/cb699f7ec5df995b9399bc671bdf0188659fb1e7/src/OpenApiValidator.ts#L170
Per AJV's issues and documentation, a significant change was made between v6->v7 where it is expected for consumers to only call compile once. A potential solution would be to evaluate
this.validate(method, match.path)as part of the initialization of the middleware, for each path, and cache the result once. Or, lazily initialize the cache on the first invocation. It sounds like they intend for this cache to be available to the application globally. This way in the middleware it's just retrieving the outcome from the cache rather than recompiling the schemas on every request, thus causing the memory leak.Another potential solution mentioned in the issue discussion is using the ajv option
addUsedSchema: false, but it's not the recommended solution, and per the discussion it sounds like there may be shortcomings of using it. https://github.com/ajv-validator/ajv/issues/1413 https://ajv.js.org/guide/managing-schemas.htmlThey also provided this blog post discussing the different strategies: https://www.poberezkin.com/posts/2021-02-11-ajv-version-7-big-changes-and-improvements.html#caching-compiled-schemas