Swashbuckle.aspnetcore: Potential Issue with Cyclical Reference - Resolver Error: Could not resolve reference: Not Found

[blumemd]

Hello I am experiencing an issue with Swashbuckle version 5.0.0.

I'm receiving a Resolver Error in swagger-ui specifically tied to the inclusion of a cyclical reference in one of my Interfaces.

When trying to view any endpoint definition that can return the IError interface I receive these errors. I also receive them while trying to view the Interface in the Schema definitions:
Resolver error at components.schemas.IError.properties.internalError.allOf.0.$ref Could not resolve reference: Not Found
Resolver error at components.schemas.IError.properties.internalError.$ref Could not resolve reference: Not Found
Resolver error at components.schemas.IError.properties.internalError.$ref Could not resolve reference: Not Found
Resolver error at components.schemas.IError.properties.internalError.$ref Could not resolve reference: Not Found

My interface looks like this:
c# public interface IError { Guid ErrorGuid { get; set; } string Name { get; set; } string Description { get; set; } DateTime Timestamp { get; set; } bool ExceptionThrown { get; set; } string CallerName { get; set; } string CallerMethod { get; set; } IError InternalError { get; set; } }

I'm also including a copy of the my swagger.json file from the test project I'm experiencing this issue in.
SwaggerJsonCurrent.txt

I have not tested this issue with any other cyclical references as of yet in this project. The issue may be limited to cyclical references in Interface types only.

It is very possible that I have made a mistake as well since I am relatively new to swashbuckle and swagger ui.

Thank you for taking a look!

[kjachmann]

Hi there, I just ran into the same issue.
I'm pretty sure it's caused by cyclic refs often used as navigation props in ef (core).
Here's my code:

public class Movie
 {
    public int Id { get; set; }
    public string Filename { get; set; }
    public string Url { get; set; }
    public string Title { get; set; }
    public DateTime Changed { get; set; }
    public DateTime Created { get; set; }
    public List<MovieTag> Tags { get; set; }
 }
 public class MovieTag
 {
    public int Id { get; set; }
    public string TagName { get; set; }
    public int MovieId { get; set; }
    public virtual Movie Movie { get; set; }
 }

My workaround was to create dedicated objects without the virtual navigation property "Movie" in MovieTags of my controllers.

Additionally, I observed stacking up the lookup-path for the json-file:
instead of
http://some.host/swagger/v1/swagger.json,
it requests
http://some.host/swagger/v1/v1/swagger.json,
http://some.host/swagger/v1/v1/v1/v1/swagger.json,
http://some.host/swagger/v1/v1/v1/v1/v1/v1/swagger.json,

Hope it helps :)

[jg11jg]

I have same issue. In my case I'm not using Entity Framework, but my objects have properties which are of same type as the objects. And I'm getting Resolver Error: Could not resolve reference: Not Found

[domaindrivendev]

I'm unable to repro this on either 5.0.0 or 5.1.0. Would it be possible for someone on this thread to put together a sample application from scratch that repro's this issue (using v5.1.0 of SB) and post it up on github? Without a repro I can't troubleshoot so that would be the first step toward progress on this issue. Thanks

[Cybrosys]

Hi,

Not exactly the same, but it's to do with cyclic reference data structures that causes the same error. Just add a method that returns the below Dto so that the Schema is generated.

If you try and look at it then you'll get the error:
Resolver error at ...
Could not resolve reference: Not Found

public class ItemDto
{
    public string Id { get; set; }
    public List<ItemDto> Items { get; set; }
}

I don't get the error if I use the online swagger editor:
https://editor.swagger.io/

I'm using 5.1.0.

[domaindrivendev]

Like I said, I can't repro this locally. @Cybrosys I used the exact class definition from your example above and am using 5.1.0. If you want me to troubleshoot further please create a minimal project with the repro and push it up to github so I have something to work with.

[Cybrosys]

Hello @domaindrivendev , please find a sample here:
https://github.com/Cybrosys/Sandbox/tree/master/Swashbuckle/WebApplication1

Repro steps:

1. Build and launch, for me it launched on http://localhost:49427/swagger/index.html
2. Click on WeatherForecast in Schemas.
3. An error is shown at the top saying:

Errors

Resolver error at components.schemas.WeatherForecast.properties.childWeatherForecasts.items.$ref
Could not resolve reference: Not Found

[domaindrivendev]

@Cybrosys the "page-relative" path in the following configuration is causing this problem:

app.UseSwaggerUI(c =>
{
    // Issue: https://github.com/swagger-api/swagger-ui/issues/4107
    // Have to have "./" infront to get a working link.
    c.SwaggerEndpoint("./v1/swagger.json", "API");
});

It seems the swagger-ui has more than 1 issue related to the use of "page-relative" URLs. If you replace it with a "root-relative" URL as folllows then this _should_ resolve your issue AND you should still get a valid link:

app.UseSwaggerUI(c =>
{
    c.SwaggerEndpoint("/swagger/v1/swagger.json", "API");
});

[akrock]

@domaindrivendev That is really unfortunate that it needs to be root relative. There are valid use cases where upon startup we would not know the external root relative URL of our service (reverse proxy)

Is there anywhere we can hijack this on a per request basis when we would know the full path to the executing code? Otherwise we are stuck at 5.0.0-RC2 until these issues with page relative paths are resolved.

[domaindrivendev]

I agree this is certainly problematic as the "page-relative" URL's are very useful for configurations that are agnostic of proxy / virtual directory based hosting. However, it's ultimately a bug with the swagger-ui library and not with Swashbuckle. Has anyone created an issue in that repo? If not, I would recommend doing so.

[domaindrivendev]

I went ahead and created the following issue in the swagger-ui repo.

[domaindrivendev]

In lieu of an upstream fix, I've just checked a SB change to workaround the issue by expanding "page-relative" URLs to a fully-qualified URLs on the client-side before passing to the SwaggerUI javascript component:

You can try it out by pulling the latest SB preview build from myget.org. Let me know how it goes?