Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fake event module result #186

Merged
merged 1 commit into from
Jun 2, 2020
Merged

Fake event module result #186

merged 1 commit into from
Jun 2, 2020

Conversation

tadeboro
Copy link
Contributor

Sensu Go backend processes events in an asynchronous fashion, which makes it almost impossible to retrieve the processed event shortly after it has been sent to the backend.

Currently, after we submit an event, we query the backend for the last event. What we get back is one of the following three options:

  1. nothing, if our event is the first event ever and the backend did not manage to process it yet;
  2. previous event, if there is at least one preexisting event on the backend and our event has not been processed yet;
  3. our actual event, if the backend processed our event fast enough.

In the real world setting, the third scenario almost never happens, which means that our event module is returning bogus results most of the time.

To rectify the situation, we now simply return back the payload we sent to the backend. This ensures that we return back relevant pieces of information instead of some random or event or even none.

@tadeboro
Copy link
Contributor Author

An alternative solution is presented in #185

Sensu Go backend processes events in asynchronous fashion, which makes
it almost impossible to retrieve the processed event shortly after it
has been sent to the backend.

Currently, after we submit an event, we query the backend for the last
event. What we get back is one of the following three options:

 1. nothing, if our event is the first event ever and the backend did
    not manage to process it yet;
 2. previous event, if there is at least one preexisting event on the
    backend and our event has not been processed yet;
 3. our actual event, if the backend processed our event fast enough.

In the real world setting, the third scenario almost never happens,
which means that our event module is returning bogus results most of
the time.

To rectify the situation, we now simply return back the payload we sent
to the backend. This ensures that we return back relevant pieces of
information instead of some random or event or even none.
@tadeboro tadeboro force-pushed the fake-object-in-event-module branch from e66e3e9 to 25925ef Compare May 17, 2020 13:05
@tadeboro
Copy link
Contributor Author

We decided to go through the deprecation cycle with the result modification. This PR introduces the deprecation and a temporary workaround, and we repurposed the #185 to clean the deprecation and remove the object result field.

Copy link
Contributor

@aljazkosir aljazkosir left a comment

Choose a reason for hiding this comment

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

Thanks @tadeboro

@aljazkosir aljazkosir merged commit cfba7c4 into master Jun 2, 2020
@aljazkosir aljazkosir deleted the fake-object-in-event-module branch June 2, 2020 09:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants