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

Fix: do not set free memory and is low memory fields when it's a NDK hard crash #1399

Merged
merged 8 commits into from Apr 21, 2021

Conversation

marandaneto
Copy link
Contributor

@marandaneto marandaneto commented Apr 14, 2021

📜 Description

💡 Motivation and Context

#1395

💚 How did you test it?

📝 Checklist

  • I reviewed the submitted code
  • I added tests to verify the changes
  • I updated the docs if needed
  • No breaking changes

🔮 Next steps

@marandaneto
Copy link
Contributor Author

@bruno-garcia let's discuss this, there are more device data that is nonstatic and should not be applied if it's a hard crash.
I'm afraid that not setting them would make the device context too poor, lets decide case by case?

@@ -314,12 +316,15 @@ private void setArchitectures(final @NotNull Device device) {
device.setModelId(Build.ID);
setArchitectures(device);

// likely to be applied only if applyScopeData
Copy link
Contributor Author

Choose a reason for hiding this comment

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

the chances that the user opens the app again right away is high, so this won't change much

Copy link
Member

Choose a reason for hiding this comment

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

Even though it's more likely that an app that crashes is reopened immediately by the user, I believe we can agree this is also not the case sometimes. And this sometimes multipled by the number of events we'll get through it'll be millions of false data.

That said, we could 'meet in the middle' and verify the timestamp of the event being within "n seconds" of the current time. And if so, apply any of such data.

Similar approach could be used with the performance product (transactions) for data that is costly to retrieve, so that we cache the value for that amount of seconds and hence, accept that the value could be slightly off from when the event actually happened.
How does that sound?

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 still think the right approach would be doing that thru sentry-native
getsentry/sentry-native#520
hence I'm going to remove free memory and is low memory on this PR, but let's collaborate on the other fields/approach in another PR.

@codecov-io
Copy link

Codecov Report

Merging #1399 (d741298) into main (4bc4353) will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff            @@
##               main    #1399   +/-   ##
=========================================
  Coverage     75.73%   75.73%           
  Complexity     1861     1861           
=========================================
  Files           185      185           
  Lines          6371     6371           
  Branches        637      637           
=========================================
  Hits           4825     4825           
  Misses         1258     1258           
  Partials        288      288           

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4bc4353...d741298. Read the comment docs.

@marandaneto marandaneto marked this pull request as ready for review April 19, 2021 09:06
@marandaneto marandaneto changed the title Fix: apply device non static data only if not hard crash Fix: do not set free memory and is low memory fields when it's a NDK hard crash Apr 19, 2021
@marandaneto marandaneto requested a review from a team April 20, 2021 11:30
Copy link
Member

@bruno-garcia bruno-garcia left a comment

Choose a reason for hiding this comment

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

Lgtm

Copy link
Member

@philipphofmann philipphofmann left a comment

Choose a reason for hiding this comment

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

LGTM

@@ -302,7 +304,7 @@ private void setArchitectures(final @NotNull Device device) {

// we can get some inspiration here
// https://github.com/flutter/plugins/blob/master/packages/device_info/android/src/main/java/io/flutter/plugins/deviceinfo/DeviceInfoPlugin.java
private @NotNull Device getDevice() {
private @NotNull Device getDevice(final boolean applyScopeData) {
Copy link
Member

Choose a reason for hiding this comment

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

l: Maybe we can find a better name for applyScopeData. We use it to control whether we add free and low memory. The name could reflect that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

the naming cant be related to free memory, because the same flag would be used to every nonstatic data that cant be applied after the restart, so it's pretty much how we call on every integration that has such check, applyScopeData

@marandaneto marandaneto merged commit c37df94 into main Apr 21, 2021
@marandaneto marandaneto deleted the fix/device-scope-data branch April 21, 2021 14:37
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

4 participants