New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MaxExpansionDepth of 0 Is Not Honored #731

Closed
foobardog opened this Issue May 16, 2016 · 2 comments

Comments

Projects
None yet
2 participants
@foobardog

foobardog commented May 16, 2016

When using setting the MaxExpansionDepth of the EnableQueryAttribute on a controller action to 0, validation is disabled as expected, but execution of the query treats it as if it was set to 2, the default.

Assemblies affected

I ran into this using the Microsoft.AspNet.OData nuGet package version 5.9.0 .

Reproduce steps

  1. Add an EnableQueryAttribute to an ODataController action, setting the MaxExpansionDepth to 0:

            [EnableQuery(MaxExpansionDepth = 0)]
            public SingleResult<WorkEntity> Get([FromODataUri] Guid key)
            {
                var result = _db.Works.Where(w => w.Identifier.Equals(key));
                return SingleResult.Create(result);
            }
  2. Start the controller, and make a query on the action, using a $levels setting above 2 (such as 3):
    http://localhost:57688/api/Works(394B7634-3E03-41C8-8B43-02EB6302C30D)?$expand=Comments($levels=3)

    Note: Comments is a navigation property going back to the Works entity set.

Expected result

The Work entity is returned, with 3 levels of the Comments property expanded.

Actual result

A 500 Internal Server Error is returned:

{
  "error": {
    "code": "",
    "message": "An error has occurred.",
    "innererror": {
      "message": "Value cannot be null.\r\nParameter name: value",
      "type": "System.ArgumentNullException",
      "stacktrace": "   at System.Web.OData.Extensions.HttpRequestMessageProperties.set_SelectExpandClause(SelectExpandClause value)\r\n   at System.Web.OData.Query.ODataQueryOptions.ApplySelectExpand[T](T entity, ODataQuerySettings querySettings)\r\n   at System.Web.OData.Query.ODataQueryOptions.ApplyTo(IQueryable query, ODataQuerySettings querySettings)\r\n   at System.Web.OData.EnableQueryAttribute.ApplyQuery(IQueryable queryable, ODataQueryOptions queryOptions)\r\n   at System.Web.OData.EnableQueryAttribute.ExecuteQuery(Object response, HttpRequestMessage request, HttpActionDescriptor actionDescriptor)\r\n   at System.Web.OData.EnableQueryAttribute.OnActionExecuted(HttpActionExecutedContext actionExecutedContext)\r\n   at System.Web.Http.Filters.ActionFilterAttribute.OnActionExecutedAsync(HttpActionExecutedContext actionExecutedContext, CancellationToken cancellationToken)\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at System.Web.Http.Filters.ActionFilterAttribute.<CallOnActionExecutedAsync>d__5.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at System.Web.Http.Filters.ActionFilterAttribute.<ExecuteActionFilterAsyncCore>d__0.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at System.Web.Http.Controllers.ActionFilterResult.<ExecuteAsync>d__2.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at System.Web.Http.Dispatcher.HttpControllerDispatcher.<SendAsync>d__1.MoveNext()"
    }
  }
}

Additional details

If you supply max instead of a number:

http://localhost:57688/api/Works(394B7634-3E03-41C8-8B43-02EB6302C30D)?$expand=Comments($levels=max)

Results are returned, but only to the second level, rather than all levels as I expected.

The issue seems to be due to the Validate method in the SelectExpandQueryOptions class (LL 40-55):

            if (validationSettings.MaxExpansionDepth > 0)
            {
                if (selectExpandQueryOption.LevelsMaxLiteralExpansionDepth < 0)
                {
                    selectExpandQueryOption.LevelsMaxLiteralExpansionDepth = validationSettings.MaxExpansionDepth;
                }
                else if (selectExpandQueryOption.LevelsMaxLiteralExpansionDepth > validationSettings.MaxExpansionDepth)
                {
                    throw new ODataException(Error.Format(
                        SRResources.InvalidExpansionDepthValue,
                        "LevelsMaxLiteralExpansionDepth",
                        "MaxExpansionDepth"));
                }

                ValidateDepth(selectExpandQueryOption.SelectExpandClause, validationSettings.MaxExpansionDepth);
            }

Normally, if a positive number is supplied for MaxExpansionDepth, it will update the LevelsMaxLiteralExpansionDepth property on the SelectExpandQueryOption. However, with 0 supplied, this step is skipped.

LevelsMaxLiteralExpansionDepth is then set to 2 (the default) in the ProcessLevels method of SelectExpandQueryOption class (LL 282-290):

        internal SelectExpandClause ProcessLevels()
        {
            bool levelsEncountered;
            bool isMaxLevel;
            return ProcessLevels(SelectExpandClause, 
                LevelsMaxLiteralExpansionDepth < 0 ? ODataValidationSettings.DefaultMaxExpansionDepth : LevelsMaxLiteralExpansionDepth, 
                out levelsEncountered, 
                out isMaxLevel);
        }

This eventually leads to the NullArgumentException above.

A possible fix to me could be to pull the LevelsMaxLiteralExpansionDepth initialization out of the if statement in the Validate method, but it feels like the Validate method probably shouldn't be setting LevelsMaxLiteralExpansionDepth at all. But that could require a much larger refactor, so I don't know how to proceed.

An obvious workaround is just to use a very large number for MaxExpansionDepth instead of 0, and I've tested that and it works, but you'll still eventually be limited by that number rather than unlimited.

VikingsFan added a commit to VikingsFan/WebApi that referenced this issue May 18, 2016

VikingsFan added a commit to VikingsFan/WebApi that referenced this issue May 18, 2016

@VikingsFan VikingsFan self-assigned this May 18, 2016

@VikingsFan

This comment has been minimized.

Contributor

VikingsFan commented May 18, 2016

@foobardog can you help to review my PR #735 :)

@VikingsFan

This comment has been minimized.

Contributor

VikingsFan commented May 23, 2016

Merged 47e33ca

@VikingsFan VikingsFan closed this May 23, 2016

@VikingsFan VikingsFan removed the in-progress label May 23, 2016

chinadragon0515 added a commit to chinadragon0515/WebApi that referenced this issue Jul 13, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment