Description
Currently the debug endpoint (/v1/debug/exposed) is returning a HTTP status code 500 when uploading 30 keys. The problem is that the keydate of the fake keys can be outside the retention period which is not accepted. It would be nice to move the debug endpoint also to the new/refactored filter logic. Here are the very highlevel requirements for the debug-endpoint:
-
/v1/debug/exposed should accept key uploads exactly the same as /v1/gaen/exposed
In addition the header X-Device-Name must be set to identify the device of the uploading device. This device name should be stored with the keys. Fake keys can be ignored, all non-fake keys should be stored. -
/v1/debug/exposed/{batchReleaseTime} should return a Zip-File containing a file per device with the naming key_export_{deviceName} that itself is a valid Zip-File containing the uploaded keys of this device in the format that the Google/Apple EN API accepts. Only the keys uploaded on the same date as batchReleaseTime should be returned (date of the upload - not keydate!). Keys should be returned immediately, independent of if they are still valid or not.
Nice to have: If the same key is uploaded multiple times with different device names, it would be nice if it would also be returned multiple times in the download request. This might be practical if one would like to conduct multiple experiments without resetting the keys on the phone inbetween.