f4453384cb
When sending an event asynchronously, the original context used for whatever generated the event (probably a synchronous, quick HTTP context) is probably not what is wanted for sending the event, which could face delays if a consumer is backed up. I will admit myself to sometimes having "context blindness", where I just take whatever context is incoming in a function and thread it out to all calls. Normally this is the right thing to do when, say, tying downstream API calls to an upstream HTTP timeout. When making KV events, for example, we used the HTTP context for `SendEvent()`, and this can cause the events to be dropped if they aren't taken from the channel before the HTTP request finishes. In retrospect, it was probably unnecessary to include a context in the `SendEvent` interface. We keep the context in place for backwards compability, but also in case we want to use it for purposes other than timeouts and cancellations in the future. Co-authored-by: Christopher Swenson <christopher.swenson@hashicorp.com>
4 lines
92 B
Plaintext
4 lines
92 B
Plaintext
```release-note:bug
|
|
events: Ignore sending context to give more time for events to send
|
|
```
|