Null Reference Exception on Batch with Versioning

[jtTorres]

I pulled the sample aspne-api-versioning and tried adding $batch to the ODataBasicSample project and it did not work.
I followed the instructions in the wiki but still nothing. It seems like it's trying to obtain the IApiVersioningFeature but that's returning a null so it's not able to access anything else.

Here's my setup:

public void ConfigureServices( IServiceCollection services )
        {
            services.AddControllers();
            services.AddApiVersioning(
                options =>
                {
                    options.ReportApiVersions = true;
                    options.RegisterMiddleware = false;
                } );
            services.AddOData().EnableApiVersioning();
        }

public void Configure( IApplicationBuilder app, VersionedODataModelBuilder modelBuilder )
        {
            app.UseODataBatching();
            app.UseApiVersioning();
            app.UseRouting();
            app.UseEndpoints(
                endpoints =>
                {
                    var models = modelBuilder.GetEdmModels( "api" );
                    var batchHandler = new DefaultODataBatchHandler();
                    endpoints.MapControllers();
                    endpoints.MapVersionedODataRoute( "odata", "api", models, batchHandler );
                } );
        }

Here's the error message I get:
System.NullReferenceException
HResult=0x80004003
Message=Object reference not set to an instance of an object.
Source=Microsoft.AspNetCore.Mvc.Versioning
StackTrace:
at Microsoft.AspNetCore.Mvc.Routing.ApiVersionUrlHelper.get_RouteParameter() in ...\Microsoft.AspNetCore.Mvc.Versioning\Routing\ApiVersionUrlHelper.cs:line 37

[koshdim]

I also stumbled upon this. looks like integration with batch functionality does not work.

I tried to debug, created by own ODataBatchHandler and found that when context is passed into
public override async Task ProcessBatchAsync(HttpContext context, RequestDelegate nextHandler)
context.GetEndpoint() - returns null and
context.GetRouteData().Routers - empty collection.
this feels wrong. is it? my setup is the same as @jtTorres 's

[commonsensesoftware]

This is very strange. I've not seen this happen and I can't figure out how to create a repro. Does anyone have a repro? Does this happen for all requests with this setup or just batch requests specifically?

It's also possible that I've already addressed this by way of some other fix. Which version is this happening against? In particular, the forthcoming patch will contain an extension method that will create an instance of IApiVersioningFeature on demand rather than rely solely on middleware.

[jtTorres]

I just pulled the latest from this repo and added the configuration mentioned in my first post. The issue still exists. It only happens for $batch requests

I'm using POSTMAN for the request. Please see my request below:

[commonsensesoftware]

The change/fix hasn't been pushed/merged - just yet. I'm burning down the full list. I can push the branch if you're interested in trying out the changes. I see it definitely happens with a batch request. Does it still happen in a non-batch request? Just curious.

As a potential temporary workaround, you could try adding the world's simplest middleware to ensure the feature is setup. You might have to play with the order. Ultimately, there isn't anything magical about the middleware. It just adds the feature and that was primarily meant to be an optimization.

Something like this:

app.Use((context, next) =>
    {
        IApiVersioningFeature feature = new ApiVersioningFeature(context);
        context.Features.Set(feature);
        return next(context);
    });
app.UseODataBatching();
app.UseApiVersioning();

HttpContext is a monad in the request pipeline. The properties in the ApiVersioningFeature are lazy-evaluated. It shouldn't really matter where it is set as log as it is set. This should address the NRE issue.

[jtTorres]

sure, I can pull your your branch and try that first to see if that works. Just send me the name.
Everything works as expected with non-batch requests.

[commonsensesoftware]

@jtTorres the branch is dev/css/201606-fixes and has now been pushed up. Take a peek at your leisure. It's not entirely clear to me why this would only happen during a batch request. Hopefully this will be resolved in the next patch. Thanks.

[jtTorres]

@commonsensesoftware pulled your branch and made the updates for $batch described in the initial post and everything worked as expected. I'm able to do both batch and non-batch transactions.

[commonsensesoftware]

@jtTorres Great news! Thanks for confirming. This fix will be included with the PR and other changes going in. The "PM" (e.g. me) is trying everything offline as they burn down. There's just a few more issues left to address and then I'll work on getting a release out.

[jtTorres]

@commonsensesoftware thanks for looking into this. We're definitely going to be using this feature a lot in my company so we're grateful and anxiously awaiting the release. :)