Skip to content
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

Fix #1056: Remove extra method generated by "x-ms-pageable" custom nextlink operation #1281

Closed
wants to merge 2 commits into from

Conversation

AlexanderSher
Copy link
Contributor

No description provided.

@@ -85,6 +85,11 @@ public static IEnumerable<PagingMethod> BuildPagingMethods(OperationGroup operat
RestClientMethod method = restClient.GetOperationMethod(serviceRequest);
RestClientMethod? nextPageMethod = restClient.GetNextOperationMethod(serviceRequest);

if (method == nextPageMethod)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This check doesn't seem to be correct at first look. Why do we need to skip methods where get next is the same as get first?

@chamons
Copy link
Contributor

chamons commented Jun 7, 2021

So after digging some more, with a test case, Pavel and I think this is a deeper issue. We should be having paging.NextLinkOperation defined as non-null in my test case but it isn't, possibly because the code model has a recursive definition of itself.

@chamons
Copy link
Contributor

chamons commented Jun 8, 2021

Closing in favor of #1303

@chamons chamons closed this Jun 8, 2021
chamons added a commit that referenced this pull request Jun 9, 2021
…e methods (#1303)

# Description
This is a second attempt at #1281, with a bit of a deeper dig into how we ran into the situtation.

Pavel pointed out during a discussion that we really shouldn't be seeing any of these "extra" methods at the level #1281 was filtering them out. 

After applying industrial strength bisect I was able to come up with this test case:  
```yaml
!CodeModel 
operationGroups:
  - !OperationGroup 
    operations:
      - !Operation 
        language: !Languages 
          default:
            paging:
              nextLinkName: nextLink
      - !Operation 
        language: !Languages 
          default:
            paging:
              nextLinkName: nextLink
              nextLinkOperation: !Operation &ref_17
                language: !Languages 
                  default:
                    paging:
                      nextLinkName: nextLink
                      nextLinkOperation: *ref_17
      - *ref_17

```

In it this code:

```csharp
            foreach (var op in v.OperationGroups.First().Operations)
            {
                var paging = op.Language.Default.Paging;
                bool hasNextOperation = paging?.NextLinkOperation != null;
```
would return true for the second and third operation in my simplified model but the third (*ref_17) would differ in the "full" autorest.csharp model.

The culprit was surprisingly:

```
-    internal partial class Language : IDictionary<string, object>
+    internal partial class Language
```

For some, honestly unknown, reason YamlDotNet would not handle this case correctly as long as we implemented the dictionary interface. I decided against deep diving into that 3rd party dependency to understand this further. This already cost too many days. I did try bumping to latest, which failed for unrelated reasons but did not change this behavior.

Removing the IDictionary interface required adding a few fields (header, summary) that were being indirectly handled, and may require more when I test this with azure-sdk-for-net this afternoon.

Test case included for #1056 in particular.

The removals in the paging test suites are expected.
@AlexanderSher AlexanderSher deleted the Fix1056 branch June 17, 2021 21:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants