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
Fix query
#1402
Conversation
@@ -110,6 +110,11 @@ pub enum SourceChainError { | |||
#[error("The source chain was missing for a host call that requires it.")] | |||
SourceChainMissing, | |||
|
|||
#[error("The supplied query parameters contains filters that are mutually incompatible. |
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.
#[error("The supplied query parameters contains filters that are mutually incompatible. | |
#[error("The query contains filters that are mutually incompatible. |
// TODO: get feedback on whether it's OK to remove non_exhaustive | ||
// #[non_exhaustive] |
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.
I removed non_exhaustive just because I was lazy and wanted it to be easier to write my test. Also I don't think our API is stable enough to warrant niceties like this yet. I will put it back in if anyone wants it.
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.
I don't think our API is stable enough to warrant niceties like this yet
is this statement specific to the query API?
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.
If we ever want this, it'll be easier to include it sooner, specifically because of things like tests getting written without it. But I don't have an opinion otherwise.
The current CI failure has nothing to do with this PR. I think it may have to do with #1389 which was recently merged. |
test failures for "ci/circleci: slow-test" can be ignored as it's being replaced by "ci/circleci: slow-test-nextest". failures of the former won't block the PR, it's merely a cosmetic issue. |
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.
I think this might be the wrong approach. I think we want to only query the database and scratch for full ranges then filter the types in memory. So the combinations of queries should still be valid.
@@ -662,6 +662,14 @@ where | |||
/// used by the `query` host function, which crosses the wasm boundary | |||
// FIXME: This query needs to be tested. | |||
pub async fn query(&self, query: QueryFilter) -> SourceChainResult<Vec<Element>> { | |||
if query.sequence_range != ChainQueryFilterRange::Unbounded | |||
&& (query.header_type.is_some() |
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.
Why can these filters only be combined with unbounded?
@freesig precisely, query is implemented with the wrong approach, but that wasn't introduced in this PR. This PR is disabling the combinations of features that are unable to work properly due to the current approach, until we fix the approach. Specifically, the fork disambiguation part that happens in memory can't work with discontinuous items, so that's why range queries are incompatible with any kind of filter. |
I responded to the change request saying that I think it's asking for a change not introduced in this PR
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.
mostly questions from my side as i don't understand this enough to immediately approve or request changes.
i'm primarily trying to fully comprehend the introduced test, which i appreciate a lot btw.
// TODO: get feedback on whether it's OK to remove non_exhaustive | ||
// #[non_exhaustive] |
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.
I don't think our API is stable enough to warrant niceties like this yet
is this statement specific to the query API?
|
||
/// Get the hex representation of the hash bytes | ||
pub fn to_hex(&self) -> String { | ||
use std::fmt::Write; | ||
let mut s = String::with_capacity(self.hash.len()); | ||
for b in &self.hash { | ||
write!(&mut s, "{:02x}", b).ok(); | ||
} | ||
s | ||
} |
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.
subtle-encoding is already in our dependency tree, should we make use of that rather than re-inventing the wheel again, or do we want to keep that out of holo_hash specifically?
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.
I'll do that as a quick follow-up, since we already had it reinvented twice before I added a third
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.
Actually, the instance of this in holo_hash
should not be replaced with subtle-encoding, since that would require pulling in that dependency, and to_hex()
could be something useful in wasm which shouldn't require a whole extra dependency of bloat. So the case for DRYing up the remaining two instances is less compelling.
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.
👍
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.
I'm ok with merging this for now as long as we follow it up soon.
Co-authored-by: Stefan Junker <1181362+steveeJ@users.noreply.github.com>
Summary
hdk::query
, which was showing some incorrect behavior:ChainQueryFilterRange::HeaderHashRange
, extraneous elements from other authors could be returned.SourceChainError::UnsupportedQuery
.TODO: