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

RUMM-1779 Keep view active until all resources are consumed #702

Merged
merged 2 commits into from Dec 31, 2021

Conversation

maxep
Copy link
Member

@maxep maxep commented Dec 29, 2021

What and why?

Backend stop processing view updates when one view reports is_active: false.

How?

Only send the attribute is_active: false after ongoing resources are consumed.

Review checklist

  • Feature or bugfix MUST have appropriate tests (unit, integration)
  • Make sure each commit and the PR mention the Issue number or JIRA reference

@maxep maxep requested a review from a team as a code owner December 29, 2021 15:40
@maxep maxep self-assigned this Dec 29, 2021
Copy link
Collaborator

@ncreated ncreated left a comment

Choose a reason for hiding this comment

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

Looks good 👍, but I left one suggestion for spreading validation of this logic in tests - LMTWDYT.

XCTAssertEqual(event.model.view.resource.count, 1, "View should record 1 successful Resource")
XCTAssertEqual(event.model.view.error.count, 1, "View should record 1 error due to second Resource failure")
XCTAssertFalse(event.model.view.isActive ?? true, "View should be inactive")
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

This test looks good 👍, although we could also test that "SDK doesn't send view updates to completed views (to ones which received their terminal, view.isActive == false update)". How about enhancing session-level validators in RUMSessionMatcher to also integrate this assertion? It already has the notion of ViewVisit aggregating all view updates in their time order and even applying some preliminary isActive checks.

We use RUMSessionMatcher in all integration and many unit tests, so this validation would be heavily applied.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, I can have a look!
So we would basically stop sending view updates once the view is inactive?
What is the actual definition of an active view?
I worry if BE start processing inactive view events in the future, we will loose data.

Copy link
Collaborator

Choose a reason for hiding this comment

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

So we would basically stop sending view updates once the view is inactive?

This is exactly how I understand it 👍, but maybe @xgouchet can confirm this.

What is the actual definition of an active view?

I will share more context on Slack.

Copy link
Member Author

@maxep maxep Dec 30, 2021

Choose a reason for hiding this comment

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

I need further modification to actually prevent from sending update events after a view is inactive, here it just sets is_active: false
It's actually already done here, so it's just a matter of asserting this in test as you mentioned!

@maxep
Copy link
Member Author

maxep commented Dec 30, 2021

Looks like Bitrise pipeline is green, so don't know why it's reported as failing here 🤔
It's green now 🤷‍♂️

@maxep maxep requested a review from ncreated December 31, 2021 10:00
@maxep maxep merged commit 87161de into master Dec 31, 2021
@maxep maxep deleted the maxep/RUMM-1779/keep-view-active branch December 31, 2021 11:46
@ncreated ncreated mentioned this pull request Jan 11, 2022
2 tasks
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

3 participants