-
Notifications
You must be signed in to change notification settings - Fork 217
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
Historical queries: Handle large requests being truncated by the host #5026
Historical queries: Handle large requests being truncated by the host #5026
Conversation
…sking for something
ledger_fetch_completeness@65363 aka 20230220.58 vs main ewma over 20 builds from 64799 to 65360 Click to see tablemain
ledger_fetch_completeness
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we kick off the Daily CI on this PR too, that will cover a few more scenarios using recoveries, historical queries, etc., especially as part of the full test suite?
💔 All backports failed
Manual backportTo create the backport manually run:
Questions ?Please refer to the Backport tool documentation and see the Github Action logs for details |
…microsoft#5026) (cherry picked from commit 042cb8f)
…microsoft#5026) (cherry picked from commit 042cb8f) # Conflicts: # src/node/historical_queries.h
This fixes a bug in the historical query system.
It assumed that any
ledger_get_range(from, to)
write to the host ringbuffer would result in a correspondingledger_entry_range(from, to)
orledger_no_entry_range(from, to)
response from the (honest) host. This is not the case - the host applies amax_size
cap since #3986 to avoid producing writes larger than the ringbuffer can handle, so it may in fact respond withledger_entry_range(from, to_)
(withto_
<to
). This PR makes the in-enclave historical query system robust to that - able to handle partial answers, and re-request entries which weren't provided.This requires a significant rewrite of the historical query book keeping, to decouple slightly the
Store
s from the specificRequest
which triggered their fetch (with a side benefit that they are now better at sharingStore
s between multipleRequest
s, without needing to refetch).There's some knock-on changes in unit tests, a new unit test simulating the original issue, and some associated changes in the host-side
ledger.h
(removing the now-unnecessarystrict
mode, and ensuring that read responses correctly describe the prefix they contain).Opening as a draft initially so I can let the CI find any tests I've missed, will open for review once I've done another cleanup pass.