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

Only broadcast HostRemovedFromCluster when a host is part of a cluster #1611

Merged
merged 6 commits into from
Jul 11, 2023
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions lib/trento/application/projectors/host_projector.ex
Original file line number Diff line number Diff line change
Expand Up @@ -275,6 +275,16 @@ defmodule Trento.HostProjector do
end
end

def after_update(
%HostRemovedFromCluster{host_id: host_id},
_,
%{host: %Trento.HostReadModel{cluster_id: nil}}
) do
TrentoWeb.Endpoint.broadcast("monitoring:hosts", "host_details_updated", %{
id: host_id
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Is this the correct payload to broadcast? cluster_id will always be nil because of the pattern-matching, is it useful to transmit this?

Copy link
Contributor

Choose a reason for hiding this comment

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

No, we need to explicitily send cluster_id: nil, because this is the value we want to store in the frontend.
If we don't send it, actually we are not sending any information.
This message is used to merge the already stored host data in redux with the new one, where we want to set the cluster as nil

})
end

def after_update(
%HostDetailsUpdated{},
_,
Expand Down
12 changes: 10 additions & 2 deletions test/trento/application/projectors/host_projector_test.exs
Original file line number Diff line number Diff line change
Expand Up @@ -148,8 +148,12 @@ defmodule Trento.HostProjectorTest do
}

ProjectorTestHelper.project(HostProjector, event, "host_projector")
projection = Repo.get!(HostReadModel, host_id)

assert_broadcast "host_details_updated",
arbulu89 marked this conversation as resolved.
Show resolved Hide resolved
%{id: ^host_id},
1000

projection = Repo.get!(HostReadModel, host_id)
assert nil == projection.cluster_id
end

Expand All @@ -169,8 +173,12 @@ defmodule Trento.HostProjectorTest do
}

ProjectorTestHelper.project(HostProjector, event, "host_projector")
projection = Repo.get!(HostReadModel, host_id)

refute_broadcast "host_details_updated",
%{id: ^host_id},
1000
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm just a bit worried about this 1000 value.
In the refute this blocks the test until the timeout is expired, so it will be waiting for 1 second to have a green test.
Maybe we should use the default 100 value?
@CDimonaco @fabriziosestito Any suggestion on this?

Copy link
Member

Choose a reason for hiding this comment

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

I think the 1000 value was set by me when I started doing broadcast test, this was set by testing manually different values, if the default timeout is sufficient we can switch to that

Copy link
Contributor

Choose a reason for hiding this comment

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

I mean, in assert_broadcast is fine, because it will just wait until the message is sent. And it will be a long test only on failure.
The refute will always wait for the time, even in passing tests.
That's the difference

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I reduced this timeout to 100 mS 👍

Copy link
Contributor

Choose a reason for hiding this comment

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

Just a least request XD
Could you test if putting this same refute_broadcast with 100ms in the test above fails? Of course, just temporarily, in your local env.
It should fail. I want to be sure that the 100ms makes sense

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Just did on my local machine and refute_broadcast can catch messages using a timeout as low as 1 mS 😵 I guess we may see different performance in the CI environment though.


projection = Repo.get!(HostReadModel, host_id)
assert cluster_id == projection.cluster_id
end

Expand Down
Loading