-
Notifications
You must be signed in to change notification settings - Fork 7
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
feat: more analytics #161
feat: more analytics #161
Conversation
No linked issues found. Please add the corresponding issues in the pull request description. |
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.
Did you check with the data team already about these changes? You need a green light from them before changing the format/semantics of the data lake.
src/handlers/push_message.rs
Outdated
#[cfg(feature = "analytics")] | ||
if let Some(mut message_info) = analytics_option { | ||
message_info.status = status; | ||
message_info.success = status >= 200 && status < 300; |
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.
Nice to have, but isn't it enough with just status
in the table?
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.
my intention with the success field was to give echo server the responsibility to determine when a request is successful or not, given it has more context on what's being done. Given it's just
message_info.success = status >= 200 && status < 300;
I don't mind dropping the column.
Consider if in the future things becomes more complicated like if status == 2xx AND some other condition
then it would be a problem for data to determine, with this column you control whether the outcome was successful or not.
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've removed it for now
src/handlers/push_message.rs
Outdated
if let Some(mut message_info) = analytics_option { | ||
message_info.status = status; | ||
message_info.success = status >= 200 && status < 300; | ||
message_info.response_message = Some(response.body().to_string()); |
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.
Is the presence of 'response_message' the only differentiator between a request and a response?
In that case, can we have a field that tells explicitly which is which to avoid potential downstream issues?
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.
response message was so we could provide context on errors
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.
ok, I think we still need to be able to differentiate between requests and responses
Builds should be all sorted now, waiting for CI & Re-review before merge + deploy |
Description
Includes requested additional analytics
Resolves # (issue)
How Has This Been Tested?
Build locally
Due Diligence