Skip to content

Conversation

johnataylor
Copy link
Member

@johnataylor johnataylor commented Feb 9, 2021

fixes #4850 #4674

  • this adds streaming support to cloud adapter
  • we are only supporting asp core
  • this does PR does not include the additional unit tests (they are coming)

The most significant code is included in the CloudAdapter class in the integration project. Basically line 126 onwards in that class.

This codes does make some use of the existing streaming SDK integration, specifically StreamingRequestHandler. However, it keeps that dependency internal.

The most significant difference between this implementation and the existing streaming implementation is that all the outbound traffic is actually funneled through an internal HttpClient implementation that abstracts the underlying stream. There was a partial implementation of that idea but it was not wired up nor did it work. This PR does not touch that code.

The existing streaming implementation also performs a token refreshing call (per virtual "request" over the socket) in order to keep the AD registration alive, I've not yet added that.

Copy link
Member

@stevengum stevengum left a comment

Choose a reason for hiding this comment

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

I did a quick review and I'm planning on taking another pass tomorrow.

var configuration = applicationBuilder.ApplicationServices.GetService<IConfiguration>();
if (configuration != null)
{
audience = audience ?? configuration.GetSection("ToChannelFromBotOAuthScope")?.Value ?? GetBuiltinDefaultAudience(configuration);
Copy link
Member

Choose a reason for hiding this comment

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

This makes sense, but worried me for a second as there's a bit of logic (straightforward logic, but still a decent amount) that goes into populating the audience. @EricDahlvang and @DDEfromOR what do you think?

Copy link
Member Author

Choose a reason for hiding this comment

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

So I tried to keep the logic in the CloudAdapter class itself clean and so pushed configuration and defaulting logic to this helper.

Some of the complexity comes from not breaking the current method. It would be easy to get into an ambiguous overload. So the new overload just requires everything.

Yes surprisingly complicated - despite the appropriate (and improved) use of the DI helpers.

More fundamentally starting the pipe from this extension seems awkward - and dropping the return task. But that is what the current method does. (Ultimately the protocol semantics are application logic to application logic so there isn't much that can be done at this level anyhow.)

Anyhow this is just a helper - for example the adaptive runtime does not need to use this helper at all.

@johnataylor
Copy link
Member Author

also fixes #4774

@johnataylor
Copy link
Member Author

and fixes #4835

Copy link
Contributor

@mrivera-ms mrivera-ms left a comment

Choose a reason for hiding this comment

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

:shipit:

Copy link
Member

@stevengum stevengum left a comment

Choose a reason for hiding this comment

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

:shipit: 🚀

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

Labels

None yet

Projects

None yet

5 participants