Allow SocketsHttpHandler.ConnectCallback for sync requests by stephentoub · Pull Request #45300 · dotnet/runtime

stephentoub · 2020-11-28T21:38:38Z

HTTP/1.1 support with sync requests currently doesn't work when a ConnectCallback is specified, even though a developer who wanted to make synchronous requests could provide a synchronously-completing callback.

This also consolidates the connect logic across sync/async, avoids an extra delegate, etc.

Contributes to #44876
cc: @geoffkizer, @scalablecory, @ManickaP

HTTP/1.1 support with sync requests currently doesn't work when a ConnectCallback is specified, even though a developer who wanted to make synchronous requests could provide a synchronously-completing callback. This also consolidates the connect logic across sync/async, avoids an extra delegate, etc.

ghost · 2020-11-28T21:38:43Z

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

HTTP/1.1 support with sync requests currently doesn't work when a ConnectCallback is specified, even though a developer who wanted to make synchronous requests could provide a synchronously-completing callback.

This also consolidates the connect logic across sync/async, avoids an extra delegate, etc.

Contributes to #44876
cc: @geoffkizer, @scalablecory, @ManickaP

Author:	stephentoub
Assignees:	-
Labels:	`area-System.Net.Http`
Milestone:	-

ManickaP · 2020-11-30T09:05:07Z

+ // we could add a Boolean to SocketsHttpConnectionContext (https://github.com/dotnet/runtime/issues/44876) to let the callback know whether
+ // this request is sync or async. For now, log it and block.
+ Trace($"{nameof(SocketsHttpHandler.ConnectCallback)} completing asynchronously for a synchronous request.");
+ stream = streamTask.AsTask().GetAwaiter().GetResult();


Shouldn't we rather throw instead of blocking for sync?

That was what I did initially, but I think that's problematic because it's non-deterministic: if the operation happens to complete by the time we check, it won't throw, but if it doesn't, it will. That then makes it much more likely you'll only experience the failures once you deploy. We already block in other circumstances as well, e.g. if you have a MaxConnectionsPerServer set, we'll block waiting for an available connection for sync operations, rather than throwing, so not throwing here is consistent with that, too. This is different from the base Send/SendAsync methods, where in general not overriding a relevant sync method in the handler chain will deterministically fail; on top of that, all of our implementations shipped "in the box" override appropriately.

I guess my original concern will get addressed with the proper implementation of #44876, and you're reasoning makes sense here. So thanks.

stephentoub · 2020-11-28T21:38:38Z

HTTP/1.1 support with sync requests currently doesn't work when a ConnectCallback is specified, even though a developer who wanted to make synchronous requests could provide a synchronously-completing callback.

This also consolidates the connect logic across sync/async, avoids an extra delegate, etc.

Contributes to #44876
cc: @geoffkizer, @scalablecory, @ManickaP

HTTP/1.1 support with sync requests currently doesn't work when a ConnectCallback is specified, even though a developer who wanted to make synchronous requests could provide a synchronously-completing callback. This also consolidates the connect logic across sync/async, avoids an extra delegate, etc.

ghost · 2020-11-28T21:38:43Z

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

HTTP/1.1 support with sync requests currently doesn't work when a ConnectCallback is specified, even though a developer who wanted to make synchronous requests could provide a synchronously-completing callback.

This also consolidates the connect logic across sync/async, avoids an extra delegate, etc.

Contributes to #44876
cc: @geoffkizer, @scalablecory, @ManickaP

Author:	stephentoub
Assignees:	-
Labels:	`area-System.Net.Http`
Milestone:	-

ManickaP · 2020-11-30T09:05:07Z

+ // we could add a Boolean to SocketsHttpConnectionContext (https://github.com/dotnet/runtime/issues/44876) to let the callback know whether
+ // this request is sync or async. For now, log it and block.
+ Trace($"{nameof(SocketsHttpHandler.ConnectCallback)} completing asynchronously for a synchronous request.");
+ stream = streamTask.AsTask().GetAwaiter().GetResult();


Shouldn't we rather throw instead of blocking for sync?

That was what I did initially, but I think that's problematic because it's non-deterministic: if the operation happens to complete by the time we check, it won't throw, but if it doesn't, it will. That then makes it much more likely you'll only experience the failures once you deploy. We already block in other circumstances as well, e.g. if you have a MaxConnectionsPerServer set, we'll block waiting for an available connection for sync operations, rather than throwing, so not throwing here is consistent with that, too. This is different from the base Send/SendAsync methods, where in general not overriding a relevant sync method in the handler chain will deterministically fail; on top of that, all of our implementations shipped "in the box" override appropriately.

I guess my original concern will get addressed with the proper implementation of #44876, and you're reasoning makes sense here. So thanks.

stephentoub · 2020-11-28T21:38:38Z

HTTP/1.1 support with sync requests currently doesn't work when a ConnectCallback is specified, even though a developer who wanted to make synchronous requests could provide a synchronously-completing callback.

This also consolidates the connect logic across sync/async, avoids an extra delegate, etc.

Contributes to #44876
cc: @geoffkizer, @scalablecory, @ManickaP

HTTP/1.1 support with sync requests currently doesn't work when a ConnectCallback is specified, even though a developer who wanted to make synchronous requests could provide a synchronously-completing callback. This also consolidates the connect logic across sync/async, avoids an extra delegate, etc.

ghost · 2020-11-28T21:38:43Z

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

HTTP/1.1 support with sync requests currently doesn't work when a ConnectCallback is specified, even though a developer who wanted to make synchronous requests could provide a synchronously-completing callback.

This also consolidates the connect logic across sync/async, avoids an extra delegate, etc.

Contributes to #44876
cc: @geoffkizer, @scalablecory, @ManickaP

Author:	stephentoub
Assignees:	-
Labels:	`area-System.Net.Http`
Milestone:	-

ManickaP · 2020-11-30T09:05:07Z

+ // we could add a Boolean to SocketsHttpConnectionContext (https://github.com/dotnet/runtime/issues/44876) to let the callback know whether
+ // this request is sync or async. For now, log it and block.
+ Trace($"{nameof(SocketsHttpHandler.ConnectCallback)} completing asynchronously for a synchronous request.");
+ stream = streamTask.AsTask().GetAwaiter().GetResult();


Shouldn't we rather throw instead of blocking for sync?

That was what I did initially, but I think that's problematic because it's non-deterministic: if the operation happens to complete by the time we check, it won't throw, but if it doesn't, it will. That then makes it much more likely you'll only experience the failures once you deploy. We already block in other circumstances as well, e.g. if you have a MaxConnectionsPerServer set, we'll block waiting for an available connection for sync operations, rather than throwing, so not throwing here is consistent with that, too. This is different from the base Send/SendAsync methods, where in general not overriding a relevant sync method in the handler chain will deterministically fail; on top of that, all of our implementations shipped "in the box" override appropriately.

I guess my original concern will get addressed with the proper implementation of #44876, and you're reasoning makes sense here. So thanks.

stephentoub · 2020-11-28T21:38:38Z

HTTP/1.1 support with sync requests currently doesn't work when a ConnectCallback is specified, even though a developer who wanted to make synchronous requests could provide a synchronously-completing callback.

This also consolidates the connect logic across sync/async, avoids an extra delegate, etc.

Contributes to #44876
cc: @geoffkizer, @scalablecory, @ManickaP

HTTP/1.1 support with sync requests currently doesn't work when a ConnectCallback is specified, even though a developer who wanted to make synchronous requests could provide a synchronously-completing callback. This also consolidates the connect logic across sync/async, avoids an extra delegate, etc.

ghost · 2020-11-28T21:38:43Z

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

HTTP/1.1 support with sync requests currently doesn't work when a ConnectCallback is specified, even though a developer who wanted to make synchronous requests could provide a synchronously-completing callback.

This also consolidates the connect logic across sync/async, avoids an extra delegate, etc.

Contributes to #44876
cc: @geoffkizer, @scalablecory, @ManickaP

Author:	stephentoub
Assignees:	-
Labels:	`area-System.Net.Http`
Milestone:	-

ManickaP · 2020-11-30T09:05:07Z

+ // we could add a Boolean to SocketsHttpConnectionContext (https://github.com/dotnet/runtime/issues/44876) to let the callback know whether
+ // this request is sync or async. For now, log it and block.
+ Trace($"{nameof(SocketsHttpHandler.ConnectCallback)} completing asynchronously for a synchronous request.");
+ stream = streamTask.AsTask().GetAwaiter().GetResult();


Shouldn't we rather throw instead of blocking for sync?

That was what I did initially, but I think that's problematic because it's non-deterministic: if the operation happens to complete by the time we check, it won't throw, but if it doesn't, it will. That then makes it much more likely you'll only experience the failures once you deploy. We already block in other circumstances as well, e.g. if you have a MaxConnectionsPerServer set, we'll block waiting for an available connection for sync operations, rather than throwing, so not throwing here is consistent with that, too. This is different from the base Send/SendAsync methods, where in general not overriding a relevant sync method in the handler chain will deterministically fail; on top of that, all of our implementations shipped "in the box" override appropriately.

I guess my original concern will get addressed with the proper implementation of #44876, and you're reasoning makes sense here. So thanks.

stephentoub · 2020-11-28T21:38:38Z

HTTP/1.1 support with sync requests currently doesn't work when a ConnectCallback is specified, even though a developer who wanted to make synchronous requests could provide a synchronously-completing callback.

This also consolidates the connect logic across sync/async, avoids an extra delegate, etc.

Contributes to #44876
cc: @geoffkizer, @scalablecory, @ManickaP

HTTP/1.1 support with sync requests currently doesn't work when a ConnectCallback is specified, even though a developer who wanted to make synchronous requests could provide a synchronously-completing callback. This also consolidates the connect logic across sync/async, avoids an extra delegate, etc.

ghost · 2020-11-28T21:38:43Z

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

HTTP/1.1 support with sync requests currently doesn't work when a ConnectCallback is specified, even though a developer who wanted to make synchronous requests could provide a synchronously-completing callback.

This also consolidates the connect logic across sync/async, avoids an extra delegate, etc.

Contributes to #44876
cc: @geoffkizer, @scalablecory, @ManickaP

Author:	stephentoub
Assignees:	-
Labels:	`area-System.Net.Http`
Milestone:	-

ManickaP · 2020-11-30T09:05:07Z

+ // we could add a Boolean to SocketsHttpConnectionContext (https://github.com/dotnet/runtime/issues/44876) to let the callback know whether
+ // this request is sync or async. For now, log it and block.
+ Trace($"{nameof(SocketsHttpHandler.ConnectCallback)} completing asynchronously for a synchronous request.");
+ stream = streamTask.AsTask().GetAwaiter().GetResult();


Shouldn't we rather throw instead of blocking for sync?

That was what I did initially, but I think that's problematic because it's non-deterministic: if the operation happens to complete by the time we check, it won't throw, but if it doesn't, it will. That then makes it much more likely you'll only experience the failures once you deploy. We already block in other circumstances as well, e.g. if you have a MaxConnectionsPerServer set, we'll block waiting for an available connection for sync operations, rather than throwing, so not throwing here is consistent with that, too. This is different from the base Send/SendAsync methods, where in general not overriding a relevant sync method in the handler chain will deterministically fail; on top of that, all of our implementations shipped "in the box" override appropriately.

I guess my original concern will get addressed with the proper implementation of #44876, and you're reasoning makes sense here. So thanks.

stephentoub · 2020-11-28T21:38:38Z

HTTP/1.1 support with sync requests currently doesn't work when a ConnectCallback is specified, even though a developer who wanted to make synchronous requests could provide a synchronously-completing callback.

This also consolidates the connect logic across sync/async, avoids an extra delegate, etc.

Contributes to #44876
cc: @geoffkizer, @scalablecory, @ManickaP

HTTP/1.1 support with sync requests currently doesn't work when a ConnectCallback is specified, even though a developer who wanted to make synchronous requests could provide a synchronously-completing callback. This also consolidates the connect logic across sync/async, avoids an extra delegate, etc.

ghost · 2020-11-28T21:38:43Z

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

HTTP/1.1 support with sync requests currently doesn't work when a ConnectCallback is specified, even though a developer who wanted to make synchronous requests could provide a synchronously-completing callback.

This also consolidates the connect logic across sync/async, avoids an extra delegate, etc.

Contributes to #44876
cc: @geoffkizer, @scalablecory, @ManickaP

Author:	stephentoub
Assignees:	-
Labels:	`area-System.Net.Http`
Milestone:	-

ManickaP · 2020-11-30T09:05:07Z

+ // we could add a Boolean to SocketsHttpConnectionContext (https://github.com/dotnet/runtime/issues/44876) to let the callback know whether
+ // this request is sync or async. For now, log it and block.
+ Trace($"{nameof(SocketsHttpHandler.ConnectCallback)} completing asynchronously for a synchronous request.");
+ stream = streamTask.AsTask().GetAwaiter().GetResult();


Shouldn't we rather throw instead of blocking for sync?

That was what I did initially, but I think that's problematic because it's non-deterministic: if the operation happens to complete by the time we check, it won't throw, but if it doesn't, it will. That then makes it much more likely you'll only experience the failures once you deploy. We already block in other circumstances as well, e.g. if you have a MaxConnectionsPerServer set, we'll block waiting for an available connection for sync operations, rather than throwing, so not throwing here is consistent with that, too. This is different from the base Send/SendAsync methods, where in general not overriding a relevant sync method in the handler chain will deterministically fail; on top of that, all of our implementations shipped "in the box" override appropriately.

I guess my original concern will get addressed with the proper implementation of #44876, and you're reasoning makes sense here. So thanks.

stephentoub · 2020-11-28T21:38:38Z

HTTP/1.1 support with sync requests currently doesn't work when a ConnectCallback is specified, even though a developer who wanted to make synchronous requests could provide a synchronously-completing callback.

This also consolidates the connect logic across sync/async, avoids an extra delegate, etc.

Contributes to #44876
cc: @geoffkizer, @scalablecory, @ManickaP

HTTP/1.1 support with sync requests currently doesn't work when a ConnectCallback is specified, even though a developer who wanted to make synchronous requests could provide a synchronously-completing callback. This also consolidates the connect logic across sync/async, avoids an extra delegate, etc.

ghost · 2020-11-28T21:38:43Z

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

HTTP/1.1 support with sync requests currently doesn't work when a ConnectCallback is specified, even though a developer who wanted to make synchronous requests could provide a synchronously-completing callback.

This also consolidates the connect logic across sync/async, avoids an extra delegate, etc.

Contributes to #44876
cc: @geoffkizer, @scalablecory, @ManickaP

Author:	stephentoub
Assignees:	-
Labels:	`area-System.Net.Http`
Milestone:	-

ManickaP · 2020-11-30T09:05:07Z

+ // we could add a Boolean to SocketsHttpConnectionContext (https://github.com/dotnet/runtime/issues/44876) to let the callback know whether
+ // this request is sync or async. For now, log it and block.
+ Trace($"{nameof(SocketsHttpHandler.ConnectCallback)} completing asynchronously for a synchronous request.");
+ stream = streamTask.AsTask().GetAwaiter().GetResult();


Shouldn't we rather throw instead of blocking for sync?

That was what I did initially, but I think that's problematic because it's non-deterministic: if the operation happens to complete by the time we check, it won't throw, but if it doesn't, it will. That then makes it much more likely you'll only experience the failures once you deploy. We already block in other circumstances as well, e.g. if you have a MaxConnectionsPerServer set, we'll block waiting for an available connection for sync operations, rather than throwing, so not throwing here is consistent with that, too. This is different from the base Send/SendAsync methods, where in general not overriding a relevant sync method in the handler chain will deterministically fail; on top of that, all of our implementations shipped "in the box" override appropriately.

I guess my original concern will get addressed with the proper implementation of #44876, and you're reasoning makes sense here. So thanks.

stephentoub · 2020-11-28T21:38:38Z

HTTP/1.1 support with sync requests currently doesn't work when a ConnectCallback is specified, even though a developer who wanted to make synchronous requests could provide a synchronously-completing callback.

This also consolidates the connect logic across sync/async, avoids an extra delegate, etc.

Contributes to #44876
cc: @geoffkizer, @scalablecory, @ManickaP

HTTP/1.1 support with sync requests currently doesn't work when a ConnectCallback is specified, even though a developer who wanted to make synchronous requests could provide a synchronously-completing callback. This also consolidates the connect logic across sync/async, avoids an extra delegate, etc.

ghost · 2020-11-28T21:38:43Z

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

HTTP/1.1 support with sync requests currently doesn't work when a ConnectCallback is specified, even though a developer who wanted to make synchronous requests could provide a synchronously-completing callback.

This also consolidates the connect logic across sync/async, avoids an extra delegate, etc.

Contributes to #44876
cc: @geoffkizer, @scalablecory, @ManickaP

Author:	stephentoub
Assignees:	-
Labels:	`area-System.Net.Http`
Milestone:	-

ManickaP · 2020-11-30T09:05:07Z

+ // we could add a Boolean to SocketsHttpConnectionContext (https://github.com/dotnet/runtime/issues/44876) to let the callback know whether
+ // this request is sync or async. For now, log it and block.
+ Trace($"{nameof(SocketsHttpHandler.ConnectCallback)} completing asynchronously for a synchronous request.");
+ stream = streamTask.AsTask().GetAwaiter().GetResult();


Shouldn't we rather throw instead of blocking for sync?

That was what I did initially, but I think that's problematic because it's non-deterministic: if the operation happens to complete by the time we check, it won't throw, but if it doesn't, it will. That then makes it much more likely you'll only experience the failures once you deploy. We already block in other circumstances as well, e.g. if you have a MaxConnectionsPerServer set, we'll block waiting for an available connection for sync operations, rather than throwing, so not throwing here is consistent with that, too. This is different from the base Send/SendAsync methods, where in general not overriding a relevant sync method in the handler chain will deterministically fail; on top of that, all of our implementations shipped "in the box" override appropriately.

I guess my original concern will get addressed with the proper implementation of #44876, and you're reasoning makes sense here. So thanks.

Dotnet-GitSync-Bot added the area-System.Net.Http label Nov 28, 2020

ManickaP reviewed Nov 30, 2020
View reviewed changes

ManickaP approved these changes Nov 30, 2020
View reviewed changes

geoffkizer approved these changes Nov 30, 2020
View reviewed changes

stephentoub merged commit 296f4de into dotnet:masterNov 30, 2020

stephentoub deleted the syncconnectcallback branch November 30, 2020 18:52

stephentoub mentioned this pull request Nov 30, 2020
Fix PlaintextStreamFilter for sync requests #45388
Merged

ghost locked as resolved and limited conversation to collaborators Dec 30, 2020

karelz added this to the 6.0.0 milestone Jan 26, 2021

Dotnet-GitSync-Bot added the area-System.Net.Http label Nov 28, 2020

ManickaP reviewed Nov 30, 2020
View reviewed changes

ManickaP approved these changes Nov 30, 2020
View reviewed changes

geoffkizer approved these changes Nov 30, 2020
View reviewed changes

stephentoub merged commit 296f4de into dotnet:masterNov 30, 2020

stephentoub deleted the syncconnectcallback branch November 30, 2020 18:52

stephentoub mentioned this pull request Nov 30, 2020
Fix PlaintextStreamFilter for sync requests #45388
Merged

ghost locked as resolved and limited conversation to collaborators Dec 30, 2020

karelz added this to the 6.0.0 milestone Jan 26, 2021

Dotnet-GitSync-Bot added the area-System.Net.Http label Nov 28, 2020

ManickaP reviewed Nov 30, 2020
View reviewed changes

ManickaP approved these changes Nov 30, 2020
View reviewed changes

geoffkizer approved these changes Nov 30, 2020
View reviewed changes

stephentoub merged commit 296f4de into dotnet:masterNov 30, 2020

stephentoub deleted the syncconnectcallback branch November 30, 2020 18:52

stephentoub mentioned this pull request Nov 30, 2020
Fix PlaintextStreamFilter for sync requests #45388
Merged

ghost locked as resolved and limited conversation to collaborators Dec 30, 2020

karelz added this to the 6.0.0 milestone Jan 26, 2021

Dotnet-GitSync-Bot added the area-System.Net.Http label Nov 28, 2020

ManickaP reviewed Nov 30, 2020
View reviewed changes

ManickaP approved these changes Nov 30, 2020
View reviewed changes

geoffkizer approved these changes Nov 30, 2020
View reviewed changes

stephentoub merged commit 296f4de into dotnet:masterNov 30, 2020

stephentoub deleted the syncconnectcallback branch November 30, 2020 18:52

stephentoub mentioned this pull request Nov 30, 2020
Fix PlaintextStreamFilter for sync requests #45388
Merged

ghost locked as resolved and limited conversation to collaborators Dec 30, 2020

karelz added this to the 6.0.0 milestone Jan 26, 2021

Dotnet-GitSync-Bot added the area-System.Net.Http label Nov 28, 2020

ManickaP reviewed Nov 30, 2020
View reviewed changes

ManickaP approved these changes Nov 30, 2020
View reviewed changes

geoffkizer approved these changes Nov 30, 2020
View reviewed changes

stephentoub merged commit 296f4de into dotnet:masterNov 30, 2020

stephentoub deleted the syncconnectcallback branch November 30, 2020 18:52

stephentoub mentioned this pull request Nov 30, 2020
Fix PlaintextStreamFilter for sync requests #45388
Merged

ghost locked as resolved and limited conversation to collaborators Dec 30, 2020

karelz added this to the 6.0.0 milestone Jan 26, 2021

Dotnet-GitSync-Bot added the area-System.Net.Http label Nov 28, 2020

ManickaP reviewed Nov 30, 2020
View reviewed changes

ManickaP approved these changes Nov 30, 2020
View reviewed changes

geoffkizer approved these changes Nov 30, 2020
View reviewed changes

stephentoub merged commit 296f4de into dotnet:masterNov 30, 2020

stephentoub deleted the syncconnectcallback branch November 30, 2020 18:52

stephentoub mentioned this pull request Nov 30, 2020
Fix PlaintextStreamFilter for sync requests #45388
Merged

ghost locked as resolved and limited conversation to collaborators Dec 30, 2020

karelz added this to the 6.0.0 milestone Jan 26, 2021

Dotnet-GitSync-Bot added the area-System.Net.Http label Nov 28, 2020

ManickaP reviewed Nov 30, 2020
View reviewed changes

ManickaP approved these changes Nov 30, 2020
View reviewed changes

geoffkizer approved these changes Nov 30, 2020
View reviewed changes

stephentoub merged commit 296f4de into dotnet:masterNov 30, 2020

stephentoub deleted the syncconnectcallback branch November 30, 2020 18:52

stephentoub mentioned this pull request Nov 30, 2020
Fix PlaintextStreamFilter for sync requests #45388
Merged

ghost locked as resolved and limited conversation to collaborators Dec 30, 2020

karelz added this to the 6.0.0 milestone Jan 26, 2021

Dotnet-GitSync-Bot added the area-System.Net.Http label Nov 28, 2020

ManickaP reviewed Nov 30, 2020
View reviewed changes

ManickaP approved these changes Nov 30, 2020
View reviewed changes

geoffkizer approved these changes Nov 30, 2020
View reviewed changes

stephentoub merged commit 296f4de into dotnet:masterNov 30, 2020

stephentoub deleted the syncconnectcallback branch November 30, 2020 18:52

stephentoub mentioned this pull request Nov 30, 2020
Fix PlaintextStreamFilter for sync requests #45388
Merged

ghost locked as resolved and limited conversation to collaborators Dec 30, 2020

karelz added this to the 6.0.0 milestone Jan 26, 2021

Uh oh!

Conversation

stephentoub commented Nov 28, 2020

Uh oh!

ghost commented Nov 28, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stephentoubNov 30, 2020• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Conversation

stephentoub commented Nov 28, 2020

Uh oh!

ghost commented Nov 28, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stephentoubNov 30, 2020• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Conversation

stephentoub commented Nov 28, 2020

Uh oh!

ghost commented Nov 28, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stephentoubNov 30, 2020• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Conversation

stephentoub commented Nov 28, 2020

Uh oh!

ghost commented Nov 28, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stephentoubNov 30, 2020• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stephentoubNov 30, 2020•
edited
Loading

stephentoubNov 30, 2020•
edited
Loading

stephentoubNov 30, 2020•
edited
Loading

stephentoubNov 30, 2020•
edited
Loading

stephentoubNov 30, 2020•
edited
Loading