search

Safe2COVIDApp / bct-server

Bluetooth Contact Tracing for Covid19 - server
5 stars 1 forks source link

status/scan periodically returns 0 results #159

Open simontegg opened 4 years ago

simontegg commented 4 years ago

One issue we’ve noticed working with the bct-server is that if any funky data gets into the server the status/scan will return 0 results.

This is just a hypothesis at this point, and its not quite clear what constitutes “funky” but could be lat/longs with the wrong number of decimal places, or timestamps that are not quite the right format (JS default ISOstring includes milliseconds).

Its easy enough wipe the data when running locally but this is much harder when developing against a remote. (http://bct-server-lb-1810171334.us-west-2.elb.amazonaws.com)

danaronson commented 4 years ago

Could you provide any specific test case that exhibits this behavior?

On Wed, May 27, 2020 at 3:46 PM Simon Tegg notifications@github.com wrote:

One issue we’ve noticed working with the bct-server is that if any funky data gets into the server the status/scan will return 0 results.

This is just a hypothesis at this point, and its not quite clear what constitutes “funky” but could be lat/longs with the wrong number of decimal places, or timestamps that are not quite the right format (JS default ISOstring includes milliseconds).

Its easy enough wipe the data when running locally but this is much harder when developing against a remote. ( http://bct-server-lb-1810171334.us-west-2.elb.amazonaws.com)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Safe2COVIDApp/bct-server/issues/159, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAYRXEM5CSQVBDNZ4UXFMDRTWJ3ZANCNFSM4NMR5NTA .

simontegg commented 4 years ago

^ @peterjacobson

mitra42 commented 4 years ago

This shouldn't be happening, but I concede its possible as we haven't got around to issue #59 (throwing bad packets at server).

Best thing would be knowing any example of bad data you've thrown at it that fails.

Next best would be access login/password to a wedged server.

If you want to keep developing, then mv /tmp/*dict somewhere that we can look at later, I think we should be able to pick up enough from that to track down the problem, though its possible (in the case of bad packets) there could be a discrepancy between data in memory and on disk.

mitra42 commented 4 years ago

Both the examples you gave (wrong DP's to lat/long and having milliseconds in times should be fine (and if not we'll prioritize fixing them). But if you can find the packet format that you are sending (including an example of the time) and post it here, then I'll make sure we add it to the test suite and test it explicitly.

Anyway - I subscribe to the protocol maxim "Be liberal in what you accept, conservative in what you send". So if you are sending us packets that look reasonable, I'd rather fix the server to be tolerant.

mitra42 commented 4 years ago

Marking unrepeatable as no more info given ....