beginListActiveSessionsAndWait() does not return Sessions even though the api called by the sdk does return Sessions

[MichaMican]

• Package Name: @azure/arm-network
• Package Version: 30.2.0
• Operating system: Windows
• nodejs
  • version: 16.15.0
• browser
  • name/version: Chrome/112.0.5615.138
• typescript
  • version: 4.9.5
• Is the bug related to documentation in
  • README.md
  • source code documentation
  • SDK API docs on https://docs.microsoft.com

Describe the bug
When using "beginListActiveSessionsAndWait" of the networkclient as described in Microsoft Docs or azure-sdk-for-js sample file i do not get back any sessions as a result, even though in the networking tab the sessions do appear.


-> I have also tried it when more than one session was active at the bastion - still the function of the sdk returned an empty array
Also in the Azure portal the sessions are displayed:

To Reproduce
Steps to reproduce the behavior:

1. implement returnsAListOfCurrentlyActiveSessionsOnTheBastion() function as described in the docs
2. create a bastion
3. create vm
4. connect to vm via bastion
5. run the implemented returnsAListOfCurrentlyActiveSessionsOnTheBastion()

Expected behavior
The SDK function should return the same result as the API returns

Screenshots

Additional context
Add any other context about the problem here.

[xirzec]

Thank you @MichaMican for such a nicely detailed issue description.

[MichaMican]

Hi all,
by any chance - are there any updates on this?

( @xirzec @qiaozha @kazrael2119 )

[kazrael2119]

I can reproduce the result of your issue and am looking for the cause

[MichaMican]

Hi @kazrael2119 - were you able to find the root cause? This issue is currently a blocker for us and we need to decide if we try to implement the pagination & session acquiring on our own or if this is beeing fixed in the foreseeable future

[kazrael2119]

Hi @kazrael2119 - were you able to find the root cause? This issue is currently a blocker for us and we need to decide if we try to implement the pagination & session acquiring on our own or if this is beeing fixed in the foreseeable future

@MichaMican ,
In swagger https://github.com/Azure/azure-rest-api-specs/blob/efd49b89cbc6b44f81056affc40cb7b96b520474/specification/network/resource-manager/Microsoft.Network/stable/2022-11-01/bastionHost.json#L874 the resonse should contains "value" and "nextlink" ,
and in "value", it contains your expected behavior:https://github.com/Azure/azure-rest-api-specs/blob/efd49b89cbc6b44f81056affc40cb7b96b520474/specification/network/resource-manager/Microsoft.Network/stable/2022-11-01/bastionHost.json#L806

see the example response in swagger:https://github.com/Azure/azure-rest-api-specs/blob/efd49b89cbc6b44f81056affc40cb7b96b520474/specification/network/resource-manager/Microsoft.Network/stable/2022-11-01/examples/BastionSessionsList.json#L10

but actually, the response body doesn't follow this chema which doesn't have nextlink parameter, I think this bug is caused by this

[github-actions]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @aznetsuppgithub.

[MichaMican]

@qiaozha @kazrael2119 Any updates on this?

[qiaozha]

Service backend needs to fix this mismatch. I have been trying to contact service team, there's not much we can do in the SDK side. If you like, you may open a support ticket https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request

[MichaMican]

Hi @qiaozha i am a bit confused why this should be a backed issue? As shown in the screenshots the backend returns the correct values, and the azure portal frontend also can deal with it correctly - So I would be very suprised if this is not fixable within the SDK

[kazrael2119]

@MichaMican, The raw response is unicode encoded. And the response mey be not match with the response defined in swagger.That's why we got unexpected value: [].

[MichaMican]

Thanks for the clarification - Can you move that forward to the respective team internally?

[kazrael2119]

“service attention” label is added, we only can wait for service feedback

[MichaMican]

Any update on this?

[github-actions]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @aznetsuppgithub.

[MichaMican]

Any update on this? (@qiaozha )

[qiaozha]

I will ping service team again, but no promises here. Sorry. You probably should open a support ticket https://azure.microsoft.com/en-us/support/create-ticket which might get your issue resolved sooner.

[abhi7860]

@MichaMican Since the final state is set via 'location', have you tried implementing a LRO poll on location? Using REST client, that returns the appropriate results and should unblock you temporarily while we investigate and make a permanent fix

[MichaMican]

@abhi7860 Will take a look into it thanks for the heads up.

However a library native approach is preferred for obvious reasons - so keep me posted on the status of the fix.

[abhi7860]

@MichaMican Did this ever work for you before and recently stopped working? Perhaps, because of a package upgrade?

[MichaMican]

Hi @abhi7860 - No unfortunately not to my knowledge - I just installed the package for the first time and it did not work so I opened this issue.

[abhi7860]

https://github.com/Azure/azure-sdk-for-js/blob/main/documentation/MIGRATION-guide-for-next-generation-management-libraries.md#long-running-operations

I see that because of some recent changes devs need to implement LRO poller. I wonder if the SDK is not responding because of that

[qiaozha]

We should already eliminate the possible cause from the SDK side before reporting to service side @abhi7860 #25671 (comment) this is the root cause based on our investigation, I think it should be clear for you, feel free to let us know if it isn't.

[MichaMican]

Any updates on this? @kazrael2119 @qiaozha @abhi7860 - The problem is still persistent and in my opinion there is no simple workarround for this - i basically would have to implement the calling of the api completely on my own, hence i'd have to ditch the library alltogether