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

cleanup appstate hook, refreshTimeline on app resume, revamp clientstats #1179

Merged
merged 4 commits into from
Sep 14, 2024

Conversation

JGreenlee
Copy link
Collaborator

TimelineContext
When appstate resumes from background, refresh the timeline to avoid stale state

useAppStateChange:
Added stat reading and removed log statement (because the stat reading itself performs a log) Clean up the subscription on teardown (the return of useEffect)

clientStats:
Updated the stat keys to be typed strings, eliminating the need for statKeys. 'my_stat_key' is less verbose than importing statKeys and callingstatKeys.MY_STAT_KEY, and this approach utilizes Typescript. Updated existing clientstats readings and removed unused clientstats keys. Added new clientstats readings in useAppStateChange MultiLabelButtonGroup. Unified CLIENT_NAV_EVENT and CLIENT_TIME since they are fundamentally the same and only differ by whether the 'reading' field has a value or is null

TimelineContext
When appstate resumes from background, refresh the timeline to avoid stale state

useAppStateChange:
Added stat reading and removed log statement (because the stat reading itself performs a log)
Clean up the subscription on teardown (the return of useEffect)

clientStats:
Updated the stat keys to be typed strings, eliminating the need for statKeys. `'my_stat_key'` is less verbose than importing statKeys and calling`statKeys.MY_STAT_KEY`, and this approach utilizes Typescript.
Updated existing clientstats readings and removed unused clientstats keys.
Added new clientstats readings in useAppStateChange MultiLabelButtonGroup.
Unified CLIENT_NAV_EVENT and CLIENT_TIME since they are fundamentally the same and only differ by whether the 'reading' field has a value or is null
@JGreenlee JGreenlee force-pushed the appstate-clientstats branch 3 times, most recently from 6c25251 to 037d69c Compare September 13, 2024 18:48
Whenever the user sees an error, it will be recorded in clientStats as a `stats/client_error`
@JGreenlee JGreenlee marked this pull request as ready for review September 13, 2024 20:16
@JGreenlee JGreenlee marked this pull request as draft September 13, 2024 20:36
@JGreenlee JGreenlee marked this pull request as ready for review September 13, 2024 20:36
@JGreenlee
Copy link
Collaborator Author

JGreenlee commented Sep 13, 2024

Not sure what is going on with the checks. Failed once and it seemed like some tests were not able to run.
Re-ran and now it is stuck on "Setup the serve environment".

@shankari
Copy link
Contributor

@JGreenlee tests are now running, but all dynamic config tests are failing because we are trying to read some cordova value

    TypeError: Cannot read properties of undefined (reading 'getVersionNumber')

      19 | export function getAppVersion() {
      20 |   if (appVersion) return Promise.resolve(appVersion);
    > 21 |   return window['cordova']?.getAppVersion.getVersionNumber().then((version) => {
         |                                           ^
      22 |     appVersion = version;
      23 |     return version;
      24 |   });

      at getVersionNumber (www/js/plugin/clientStats.ts:21:43)
      at getAppVersion (www/js/plugin/clientStats.ts:29:36)
      at call (www/js/plugin/clientStats.ts:2:1)
      at Generator.tryCatch (www/js/plugin/clientStats.ts:2:1)
      at Generator._invoke [as next] (www/js/plugin/clientStats.ts:2:1)
      at asyncGeneratorStep (www/js/plugin/clientStats.ts:2:1)
      at asyncGeneratorStep (www/js/plugin/clientStats.ts:2:1)
      at _next (www/js/plugin/clientStats.ts:2:1)
      at www/js/plugin/clientStats.ts:2:1
      at apply (www/js/plugin/clientStats.ts:27:29)
      at getStatsEvent (www/js/plugin/clientStats.ts:45:23)
      at call (www/js/plugin/clientStats.ts:2:1)
      at Generator.tryCatch (www/js/plugin/clientStats.ts:2:1)
      at Generator._invoke [as next] (www/js/plugin/clientStats.ts:2:1)
      at asyncGeneratorStep (www/js/plugin/clientStats.ts:2:1)
      at asyncGeneratorStep (www/js/plugin/clientStats.ts:2:1)
      at _next (www/js/plugin/clientStats.ts:2:1)
      at www/js/plugin/clientStats.ts:2:1
      at apply (www/js/plugin/clientStats.ts:43:35)
      at displayErrorMsg (www/js/plugin/logger.ts:24:15)
      at displayErrorMsg (www/js/plugin/logger.ts:14:3)
      at _callee$ (www/js/services/commHelper.ts:30:17)
      at call (www/js/services/commHelper.ts:2:1)
      at Generator.tryCatch (www/js/services/commHelper.ts:2:1)
      at Generator._invoke [as throw] (www/js/services/commHelper.ts:2:1)
      at asyncGeneratorStep (www/js/services/commHelper.ts:2:1)
      at asyncGeneratorStep (www/js/services/commHelper.ts:2:1)

It is related to ClientStats, so does seem to be related to your changes.

in dynamicConfig.test.ts, there are some tests where an error is expected to be thrown and error popup is triggered. clientstats is invoked because we are now recording a ui_error stat on all error popups.
Client stats needs mockDevice and mockGetAppVersion to work

in startprefs.test.ts, a similar error popup occurs so the mocks are needed there too.
However, while inspecting startprefs.ts, I noticied the popup occurs when consent document exists in localstorage but not in native storage.
I do not think we need an error popup for this; instead let's do what we do in storage.ts, which is record a 'missing_keys" client stat, and give it a type of 'document_mismatch'.
Instead of having each test file call the mocks it uses, we can have jest set up all the mocks beforehand.
in jest.config.js, setupFiles points to setupJestEnv.js where all the mocks are called.

This is way less verbose, and may also speed up the execution of the test suites because the mocks are applied once rather than duplicated for every individual test.

We still have flexibility for individual tests to call mocks on their own; for example in enketoHelper.test.ts there are several calls to mockBEMUserCache(<fakeconfig>) because it is testing out various configs
Copy link

codecov bot commented Sep 14, 2024

Codecov Report

Attention: Patch coverage is 42.30769% with 15 lines in your changes missing coverage. Please review.

Project coverage is 30.14%. Comparing base (2e4f969) to head (4596d0c).
Report is 9 commits behind head on master.

Files with missing lines Patch % Lines
www/js/survey/multilabel/MultiLabelButtonGroup.tsx 0.00% 5 Missing ⚠️
www/js/Main.tsx 0.00% 4 Missing ⚠️
www/js/control/ControlSyncHelper.tsx 0.00% 2 Missing ⚠️
www/js/plugin/storage.ts 0.00% 2 Missing ⚠️
www/js/diary/cards/TripCard.tsx 0.00% 1 Missing ⚠️
www/js/useAppStateChange.ts 50.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1179      +/-   ##
==========================================
+ Coverage   30.13%   30.14%   +0.01%     
==========================================
  Files         118      118              
  Lines        5164     5172       +8     
  Branches     1108     1110       +2     
==========================================
+ Hits         1556     1559       +3     
- Misses       3606     3611       +5     
  Partials        2        2              
Flag Coverage Δ
unit 30.14% <42.30%> (+0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
www/js/TimelineContext.ts 50.60% <100.00%> (+0.30%) ⬆️
www/js/plugin/clientStats.ts 92.00% <100.00%> (+1.37%) ⬆️
www/js/plugin/logger.ts 94.11% <100.00%> (+0.36%) ⬆️
www/js/splash/notifScheduler.ts 98.37% <100.00%> (ø)
www/js/splash/remoteNotifyHandler.ts 83.33% <100.00%> (ø)
www/js/splash/startprefs.ts 95.74% <100.00%> (ø)
www/js/diary/cards/TripCard.tsx 0.00% <0.00%> (ø)
www/js/useAppStateChange.ts 60.00% <50.00%> (+60.00%) ⬆️
www/js/control/ControlSyncHelper.tsx 0.00% <0.00%> (ø)
www/js/plugin/storage.ts 58.88% <0.00%> (ø)
... and 2 more

@JGreenlee
Copy link
Collaborator Author

fix tests, record client stats for missing native consent

in dynamicConfig.test.ts, there are some tests where an error is expected to be thrown and error popup is triggered. clientstats is invoked because we are now recording a ui_error stat on all error popups.
Client stats needs mockDevice and mockGetAppVersion to work

in startprefs.test.ts, a similar error popup occurs so the mocks are needed there too.
However, while inspecting startprefs.ts, I noticied the popup occurs when consent document exists in localstorage but not in native storage.
I do not think we need an error popup for this; instead let's do what we do in storage.ts, which is record a 'missing_keys" client stat, and give it a type of 'document_mismatch'.


simplify mocking by specifying jest setup file

Instead of having each test file call the mocks it uses, we can have jest set up all the mocks beforehand.
in jest.config.js, setupFiles points to setupJestEnv.js where all the mocks are called.

This is way less verbose, and may also speed up the execution of the test suites because the mocks are applied once rather than duplicated for every individual test.

We still have flexibility for individual tests to call mocks on their own; for example in enketoHelper.test.ts there are several calls to mockBEMUserCache() because it is testing out various configs

@shankari
Copy link
Contributor

However, while inspecting startprefs.ts, I noticied the popup occurs when consent document exists in localstorage but not in native storage.
I do not think we need an error popup for this; instead let's do what we do in storage.ts, which is record a 'missing_keys" client stat, and give it a type of 'document_mismatch'.

Fair. We should record both mismatches (localstorage but not native storage, and native storage but not localstorage) as errors because that is one of the hardest issues to debug.

Copy link
Contributor

@shankari shankari left a comment

Choose a reason for hiding this comment

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

Nice! Much cleaner to put all the init into one place.
I am now merging this, and will push out to staging soon!

@shankari shankari merged commit 003c55d into e-mission:master Sep 14, 2024
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

2 participants