Hello, 

i have a serious issue with dependency injection of ContentApiModelFilters. It seems that it's always using a singleton no matter what lifecycle you use.
We have many filters and all behave as if ServiceInstance.Singleton was used. For example:

[ServiceConfiguration(typeof(IContentApiModelFilter), Lifecycle = ServiceInstanceScope.Scoped)]
public class LinkBlockContentApiModelFilter : ContentApiModelFilter<ContentApiModel>
{
	#region fields

	private readonly IUrlResolver _urlResolver;
	private readonly IContentLoader _contentLoader;
	private readonly ContentResolver _contentResolver; // this is not episerver's
	// and other fields

	#endregion

	#region constructor

	public LinkBlockContentApiModelFilter(IUrlResolver urlResolver, IContentLoader contentLoader, ContentResolver contentResolver, ILogger<LinkBlockContentApiModelFilter> logger)
	{
		_urlResolver = urlResolver;
		_contentLoader = contentLoader;
		_contentResolver = contentResolver;
                // and other fields
	}

	#endregion
	
	#region Filter()

	public override void Filter(ContentApiModel contentApiModel, ConverterContext converterContext)
	{
		// some code using the fields
    }
}
               

So the issue is that we always use the same instance of the fields used via constructor injetion. The ContentResolver for example is responsible to resolve content for a given url(using IUrlResolver.Route). But since we cache that value we always get the same content once it was resolved, on any page. 

Why is it so, are the filters used in a singleton context by episerver?

It also does not make a difference if i register it by myself:

services.AddScoped<IContentApiModelFilter, BreadcrumbContentApiModelFilter>();
services.AddScoped<IContentApiModelFilter, LinkBlockContentApiModelFilter>();
// and so on

Is the only solution to use a workaround like not using constructor injection at all but always use the ServiceProvider?

ContentResolver contentResolver = ServiceLocator.Current.GetInstance<ContentResolver>();
// now work with this which should be a scoped instance

Edit: Unfortunately it is not a solution to just implement IContentApiModelFilter instead of inheriting from ContentApiModelFilter<ContentApiModel> as Eric Herlitz has suggested. Even if you register it manually in Startup.cs via AddScoped you will have a singleton in the filter. The reason i could find out via reflection of the epi source code. ContentConvertingService is a singleton itself:

[ServiceConfiguration(Lifecycle = ServiceInstanceScope.Singleton)]
public class ContentConvertingService
{
    // ...

    public ContentConvertingService(
      //....
      IEnumerable<IContentApiModelFilter> contentApiModelFilters)
    {
      // ...
      this._contentApiModelFilters = contentApiModelFilters;
    }

    public virtual ContentApiModel ConvertToContentApiModel(IContent content, ConverterContext converterContext)
    {
      List<IContentFilter> source = content != null ? this.GetContentFilters(content.GetType()) : throw new ArgumentNullException(nameof (content));
      if (source.Any<IContentFilter>())
      {
        content = ContentConvertingService.TryGetWriteableClone(content);
        source.ForEach((Action<IContentFilter>) (c => c.Filter(content, converterContext)));
        if (content is IReadOnly readOnly)
          readOnly.MakeReadOnly();
      }
      ContentApiModel contentApiModel = this._contentConverterResolver.Resolve(content).Convert(content, converterContext);
      this.GetContentModelFilters(contentApiModel).ForEach(f => f.Filter(contentApiModel, converterContext));
      return contentApiModel;
    }
}

You either have to avoid a singleton in ContentConvertingService or find a way to resolve the filters without using constructor injection to fix this bug.