Conversation
Signed-off-by: Jose Nino <jnino@lyft.com>
|
@buildbreaker @rebello95 @goaway this PR exposes stream data buffering in order to allow for retries. I only did the work here to expose the option and wire it all the way to the underlying envoy stream. We have an open question on how we want the platform code to deal with turning on buffering, and its relation with retries. Therefore, the way I have implemented here leaves us open for several possibilities. |
|
This pull request has been automatically marked as stale because it has not had activity in the last 7 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
|
This pull request has been automatically closed because it has not had activity in the last 14 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
|
re-opening now that I am back. @goaway do you mind taking a look and if it looks good on first pass I can rebase and we can review? |
|
This pull request has been automatically marked as stale because it has not had activity in the last 7 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
|
closing this in favor of: #511 |
Description: after a bit more discussion we have decided to go ahead and make buffering configurable. This PR revives #456 Risk Level: med - adds new surface area to the API Testing: local apps and CI Signed-off-by: Jose Nino <jnino@lyft.com>
Description: this PR introduces
envoy_stream_optionswhich is a subset of AsyncClient::StreamOptions, that can be used in the bridge layer.Risk Level: med - new functionality
Testing: unit tests missing, will update after initial discussion
Signed-off-by: Jose Nino jnino@lyft.com