Questions regarding OASFilter implemations #2173

A few tests.
I created a sample quarkus app using code.quarkus.io (just rest, and openapi).
Filter Impl:

@OpenApiFilter(OpenApiFilter.RunStage.BOTH)
public class MyFilter implements OASFilter {
    @Override
    public Operation filterOperation(Operation operation) {
        System.out.println("Hello from CL: %s. TCCL: %s".formatted(this.getClass().getClassLoader().getName(), Thread.currentThread().getContextClassLoader().getName()));
        return OASFilter.super.filterOperation(operation);
    }
}

Causes the following logs at given RunStage:

RUN causes 1 log:
Hello from CL: Deployment Class Loader: DEV for soapi-filter-1.0.0-SNAPSHOT. TCCL: Deployment Class Loader: DEV for soapi-filter-1.0.0-SNAPSHOT

And another Log when opening the swagger-ui:

Hello from CL: Quarkus Runtime ClassLoader: DEV for soapi-filter-1.0.0-SNAPSHOT restart no:3. TCCL: Quarkus Runtime ClassLoader: DEV for soapi-filter-1.0.0-SNAPSHOT restart no:3

BOTH causes 2 logs:
Hello from CL: Deployment Class Loader: DEV for soapi-filter-1.0.0-SNAPSHOT. TCCL: Deployment Class Loader: DEV for soapi-filter-1.0.0-SNAPSHOT                                                                                                                                                                     
Hello from CL: Deployment Class Loader: DEV for soapi-filter-1.0.0-SNAPSHOT. TCCL: Deployment Class Loader: DEV for soapi-filter-1.0.0-SNAPSHOT


And another Log when opening the swagger-ui:
Hello from CL: Quarkus Runtime ClassLoader: DEV for soapi-filter-1.0.0-SNAPSHOT restart no:4. TCCL: Quarkus Runtime ClassLoader: DEV for soapi-filter-1.0.0-SNAPSHOT restart no:4

BUILD causes 1 log: 
Hello from CL: Deployment Class Loader: DEV for soapi-filter-1.0.0-SNAPSHOT. TCCL: Deployment Class Loader: DEV for soapi-filter-1.0.0-SNAPSHOT

Definitly seems fishy.

After a bit of debugging, found out that io.quarkus.smallrye.openapi.deployment.SmallRyeOpenApiProcessor#getUserDefinedBuildtimeFilters returns the same filter multiple times.

Same for #getUserDefinedRuntimeFilters.

In getUserDefinedFilters,

index.getAnnotations(OpenApiFilter.class)

returns the same filter twice already. Even for RUN.

Seems strange, returning the same filter multiple times from the index already.
But, does not seem related. The log indicates that the filter is first called at build time, and then later when opening swagger-ui.
Needs to be looked at anyway maybe.

@dhoffer Is something in your app automatically requesting the openapi definition? This would explain why the filter is run twice.

@MikeEdgar What exactly does the RunStage.RUN mean? Are filters with RUN only supposed to be called on initial load of the openapi doc, or after quarkus starts?

And another interesting point, the first log for the RUN filter is coming from this filter invocation:
https://github.com/quarkusio/quarkus/blob/main/extensions/smallrye-openapi/deployment/src/main/java/io/quarkus/smallrye/openapi/deployment/SmallRyeOpenApiProcessor.java#L943-L950
Why are runtime filters run in a build step? I guess just to have the stored openapi document as "filtered" as possible. But seems strange that filters explicitly marked with RUN are also included in this.

The second log, when opening swagger-ui, is caused by OpenApiDocumentService, which seems fine.

Yes we make a call to get the openapi at app startup, this is to store the 'static' part of the openapi so it's just done once. Then when users make a request to get the openapi we do some additional user filtering based on their permissions/etc. The user filter is just a pojo not an OASFilter. We do have one OASFilter that is annotated with @OpenApiFilter(OpenApiFilter.RunStage.RUN). We use this class to modify the static openapi per our customizations.

What exactly does the RunStage.RUN mean? Are filters with RUN only supposed to be called on initial load of the openapi doc, or after quarkus starts?

They will be run against the hosted OpenAPI when the server starts, but against the stored OpenAPI when the application builds. The stored OpenAPI is not the same one that is hosted at /q/openapi. As you said, the purpose is so that the stored document takes into account all the filters available.

@MikeEdgar @Postremus Our main concern is that we think we have found a latent bug in Quarkus/Smallrye-Openapi that causes classes to be loaded by different class loaders, so a Pojo Singleton is not really a Singleton at all as the 2 class loaders each loaded their own Singleton instance, obviously this breaks everything as it's not a Singleton anymore. So far we can only duplicate this issue on one developer laptop. Where so we start to track this down and resolve? I am concerned this bug could manifest at any time on any production server causing the application to fail.

Do you see the singleton loaded twice when running with java -jar yourapp.jar or with mvn quarkus:dev ?

I was not able to reproduce this when running as a uberjar with a simple filter.

Please provide a reproducer.

As a starting point to figure out if a problem exists, maybe take a look at what this filter outputs:

@OpenApiFilter(OpenApiFilter.RunStage.RUN)
public class MyFilter implements OASFilter {
    @Override
    public Operation filterOperation(Operation operation) {
        System.out.printf("Hello from Thread: %s CL: %s. TCCL: %s%n", Thread.currentThread().getName(), this.getClass().getClassLoader().getName(), Thread.currentThread().getContextClassLoader().getName());
        new Exception().printStackTrace();

        return OASFilter.super.filterOperation(operation);
    }
}

You can simply add this filter alongside your existing ones (multiple @OpenApiFilter are supported), or add the content into your existing one.