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

feat: more analytics #161

Merged
merged 8 commits into from
Jul 18, 2023
Merged

feat: more analytics #161

merged 8 commits into from
Jul 18, 2023

Conversation

HarryET
Copy link
Contributor

@HarryET HarryET commented Jul 12, 2023

Description

Includes requested additional analytics

Resolves # (issue)

How Has This Been Tested?

Build locally

Due Diligence

  • Breaking change
  • Requires a documentation update
  • Requires a e2e/integration test update

@github-actions
Copy link
Contributor

No linked issues found. Please add the corresponding issues in the pull request description.
Use GitHub automation to close the issue when a PR is merged

Copy link
Contributor

@xav xav left a 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.

#[cfg(feature = "analytics")]
if let Some(mut message_info) = analytics_option {
message_info.status = status;
message_info.success = status >= 200 && status < 300;
Copy link
Contributor

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?

Copy link

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.

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've removed it for now

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());
Copy link
Contributor

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?

Copy link
Contributor Author

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

Copy link
Contributor

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

src/handlers/push_message.rs Outdated Show resolved Hide resolved
src/handlers/push_message.rs Outdated Show resolved Hide resolved
@HarryET
Copy link
Contributor Author

HarryET commented Jul 17, 2023

Builds should be all sorted now, waiting for CI & Re-review before merge + deploy

@HarryET HarryET requested review from arein and xav July 17, 2023 20:35
@HarryET HarryET merged commit 5698d83 into main Jul 18, 2023
2 of 4 checks passed
@HarryET HarryET deleted the feat/more-analytics branch July 18, 2023 08:47
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.

None yet

5 participants