-
Notifications
You must be signed in to change notification settings - Fork 15
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
Project host FQDN #2204
Project host FQDN #2204
Conversation
0d445b6
to
cdc9e2e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 🚀
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am afraid we're missing some parts of the changing fqdn scenario.
During a host's restoration
in execute on line 173 we also need to match the fqdn between the aggregate's state and the incoming RegisterHost
command, meaning that the exact same host has been restored and so only a HostRestored
is emitted
During a host's details changes detection
in executes on lines 259 and 284 fqdn is not properly taken into account.
In the first command handling we need to match also fqdn between aggregate's state and the incoming RegisterHost
so that if they're the same no event is emitted.
In the second command handling, when the previous does not match (aka different details have been detected), we need to get the fqdn from the incoming RegisterHost
command and emit it in HostDetailsUpdated
(and of course update aggregate's state accordingly in the relevant apply)
Happy to answer any questions.
@nelsonkopliku thanks for catching that! About changes detection: totally right, I updated the code accordingly. About restoration: not a big fan of matching the FQDN in that clause because I don't think it's a relevant detail to base the restoration logic upon, but I don't have a strong opinion either. Change done. 👍 |
668ab82
to
fcae274
Compare
@dottorblaster the problem with restoration is that if all other details remain unchanged, BUT [EDIT] I guess some tests for the changing fqdn scenario are necessary |
@nelsonkopliku added a test for a changing FQDN scenario and enriched already existing expectations to include some more fqdn infos. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Everything looks fine now, thanks!
We might want to have at least one photofinish scenario sending the fqdn, for completeness.
Description
Project the FQDN sent by the agent on the host read model.
How was this tested?
Existing unit tests updated