Warn instead of failing in double hashed client #14
Conversation
Rationale is that double hashed client has a larger surface for failure comparing to the regular client. It does multiple network roundtrips as well as a number of decryption operations in order to fullfill a single lookup. We should be striving for returning a consistent result to the user even if some parts of the query might fail. Logging instead of failing will also allow us to do finer grained debugging in dhfind if necessary. The next step will be to enable streaming to reduce time to the first result.
Codecov ReportPatch coverage has no change and project coverage change:
📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more Additional details and impacted files@@ Coverage Diff @@
## main #14 +/- ##
==========================================
- Coverage 51.76% 51.62% -0.14%
==========================================
Files 56 56
Lines 4694 4695 +1
==========================================
- Hits 2430 2424 -6
- Misses 2008 2015 +7
Partials 256 256
... and 3 files with indirect coverage changes Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
can these errors happen in normal operation, or does it indicate corruption?
my expectation here is that until we get providers writing pre-encrypted records to us this is something we should be watching for, so warning in the logs is warranted.
once we have per-encrypted records we may want to think about lowering the log level
That can happen (and seems to be happening) during the normal operation. I've observed some 404s for a part of a query. I.e. when a value key exists but metadata does not for example. We know that that might happen because there are no transactions, no WAL. I will monitor that situation in dhfind. Agreed about lowering the scope once writer privacy is here. |
Rationale is that double hashed client has a larger surface for failure comparing to the regular client. It does multiple network roundtrips as well as a number of decryption operations in order to fullfill a single lookup. We should be striving for returning a consistent result to the user even if some parts of the query might fail. Logging instead of failing will also allow us to do finer grained debugging in dhfind if necessary. The next step will be to enable streaming to reduce time to the first result.