App Data Issues
- Dwayne Jeng (Unlicensed)
TODO: Once we get the YML team onto our JIRA, we can convert most of these into JIRA items.
New Features
| Feature | Status | Notes |
|---|---|---|
| New HealthKit data streams | verified in staging | See Health Kit Data for details |
Problems
| Problem | App Version | Status | Notes |
|---|---|---|---|
| duplicate filenames | version 1.0.7, build 26-YML | fixed locally fixed in prod for asthma 1.0.7, build 17 | This bug affects multiple activities across multiple apps. |
| empty sevenDayFitnessAllocation uploads (cardio, diabetes) | cardio version 1.0.6, build 9 (YML) diabetes version 1.0.8, build 2 - YML | fixed in prod for cardio 1.5 (1.0.10) | |
| empty diabetes Log Food uploads | version 1.0.8, build 2 - YML | fixed locally | not to be confused with glucose log |
Open Questions
File Size Limit
We need a file size limit, specifically to protect against a zip bomb attack (https://en.wikipedia.org/wiki/Zip_bomb). The current limits are set to 100 files in a zip archive or 25mb uncompressed size for any individual file. (We don't recursively unpack zip files.) There is also the practical concern that larger files take longer to upload and longer to process, and hence are more likely to fail.
Currently, the largest file is deviceMotion_fitness.walk in the cardio 6-Minute Walk test, weighing in at 17mb. This has been consistent over the last 3 months. This is below the 25mb threshold, but we are concerned that if files grow larger, we may get data loss.
What can we do to make sure file sizes don't grow beyond the 25mb limit? If we do need to upload that much data at once, how can we ensure that data still reaches the researchers, without exposing the Bridge server to zip bomb attacks or consuming a large number of machine resources?