refit: [BUG] Index out of bounds Error when passing array as Query if its not first parameter

Describe the bug [Get("/v1/project/{projectId}/markups")] Task<List<Users>> GetMarkups(string projectId, [Query(CollectionFormat.Multi)] string[] status); fails with: System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values. Parameter name: index at System.Linq.Enumerable.ElementAt[TSource](IEnumerable1 source, Int32 index) at Refit.RequestBuilderImplementation.<>c__DisplayClass17_0.<<BuildRequestFactoryForMethod>b__0>d.MoveNext() in d:\a\1\s\Refit\RequestBuilderImplementation.cs:line 569 — End of stack trace from previous location where exception was thrown — at Refit.RequestBuilderImplementation.<>c__DisplayClass14_02.<<BuildCancellableTaskFuncForMethod>b__0>d.MoveNext() in d:\a\1\s\Refit\RequestBuilderImplementation.cs:line 244 --- End of stack trace from previous location where exception was thrown ---

Steps To Reproduce Pass any array as Query where it is not the first parameter and it will throw. When passed as the first argument everything works fine. This works fine: [Get("/v1/project/{projectId}/markups")] Task<List<Users>> GetMarkups([Query(CollectionFormat.Multi)] string[] status, string projectId);

Expected behavior Shouldn’t throw an error should work as argument in any position

Environment

  • OS: dotnet core 2.2 on Mac
  • Version 4.7.40
  • Device: NA

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 4
  • Comments: 19 (10 by maintainers)

Most upvoted comments

Just additional confirmation, that for me at least, in 4.7.51 it is the header attribute being first and moving it to after query string values it works, and making no changes and rolling back to 4.7.9 works.

I rolled back to 4.7.9 as this is a breaking change in a patch version which should never occur. Also I would argue this type of breaking change should happen in a minor version as well. Even a major version breaking change would be bad for this impact unless there was good justification for it.

Questions for those who maintain and release refit:

  1. Why are there no release notes for 4.7.51?
  2. Why was 4.7.51 released, what are the important changes?
  3. Are there no tests around this functionality that triggered the breaking change?

I would recommend the release should be removed from GitHub and unlisting in nuget as this is is a huge breaking change. It killed just about all my refit calls and there is no way I am going to go back and refactor all of them to move the auth header from first to after the query string values.

I hope you understand the problem with that policy.

That a hotfix policy may be appropriate when you release an unexpected breaking change in a patch release so that you can fix/revert what is needed to release another patch release to address what was broken. Preferably quickly. Hotfix branches and CICD release pipelines are something that could be implemented to make it easy to manage a hotfix release.

Hey @onovotny,

this is still not fixed. I get the same with the latest 5.0.15. Here is my api definition:

[Headers("Accept:application/json", "X-API-V: 125")] [Get("/api/someModule/deviceList?controlId={control_id}")] Task<DeviceListResponse> DeviceList([Header("Authorization")] string authorization, [Header("X-Lng")] string twoLetterLang, string search, [AliasAs("control_id")] string controlId, string secret);

We still get this error: “Specified argument was out of the range of valid values.\nParameter name: index”

When i set the header arguments to the end of the method its working. Example: [Headers("Accept:application/json", "X-API-V: 125")] [Get("/api/someModule/deviceList?controlId={control_id}")] Task<DeviceListResponse> DeviceList(string search, [AliasAs("control_id")] string controlId, string secret, [Header("X-Lng")] string twoLetterLang, [Header("Authorization")] string authorization);

To change this everywhere in all my libraries and apps is no possible solution. We sharing library codes across app and server in some projects. I rly cannot refactor all of this for sure. I revert back to 4.6.107 now. What is very important to know if you can provide a fix for this bug. Or isn’t it a bug?

Thx a lot Stefan

@onovotny picking this up today alongside #696 and #587, hopefully I can get a PR in by tomorrow

Thanks. The CI feed is now on Azure Artifacts now btw.

Let’s ensure we have test cases that cover these scenarios too.

Hello,

Having the same problem when using the multi parameter in the Query attribute

Here’s the signature of the problematic method [Get("/api/v1/user/info")] Task<IEnumerable<UserInformation>> GetUserInformationAsync([Header("Authorization")] string authorization, [Query(CollectionFormat.Multi)][AliasAs("userId")]IEnumerable<string> userIds);

However this works [Get("/api/v1/user/info")] Task<IEnumerable<UserInformation>> GetUserInformationAsync([Query(CollectionFormat.Multi)][AliasAs("userId")]string[] userIds, [Header("Authorization")] string authorization);