Skip to content
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

Merged
merged 8 commits into from Jul 14, 2022
Merged

Fix query #1402

merged 8 commits into from Jul 14, 2022

Conversation

maackle
Copy link
Member

@maackle maackle commented Jun 1, 2022

Summary

  • Fixed hdk::query, which was showing some incorrect behavior:
    • When using ChainQueryFilterRange::HeaderHashRange, extraneous elements from other authors could be returned.
    • Certain combinations of filters, like hash-bounded ranges and header type filters, are currently implemented incorrectly and lead to undefined behavior. Filter combinations which are unsupported now result in SourceChainError::UnsupportedQuery.

TODO:

  • CHANGELOG(s) updated with appropriate info
  • Just before pressing the merge button, ensure new entries to CHANGELOG(s) are still under the UNRELEASED heading

@@ -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.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
#[error("The supplied query parameters contains filters that are mutually incompatible.
#[error("The query contains filters that are mutually incompatible.

Comment on lines +64 to +65
// TODO: get feedback on whether it's OK to remove non_exhaustive
// #[non_exhaustive]
Copy link
Member Author

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.

Copy link
Member

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?

Copy link
Contributor

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.

@maackle
Copy link
Member Author

maackle commented Jun 2, 2022

The current CI failure has nothing to do with this PR. I think it may have to do with #1389 which was recently merged.

@steveej
Copy link
Member

steveej commented Jun 2, 2022

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.

@maackle maackle requested a review from zo-el June 7, 2022 19:01
Copy link
Contributor

@freesig freesig left a 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()
Copy link
Contributor

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?

@maackle
Copy link
Member Author

maackle commented Jun 28, 2022

@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.

@maackle maackle requested a review from freesig June 28, 2022 18:09
@maackle maackle dismissed freesig’s stale review July 5, 2022 16:57

I responded to the change request saying that I think it's asking for a change not introduced in this PR

Copy link
Member

@steveej steveej left a 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.

Comment on lines +64 to +65
// TODO: get feedback on whether it's OK to remove non_exhaustive
// #[non_exhaustive]
Copy link
Member

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?

crates/holochain_state/src/source_chain.rs Show resolved Hide resolved
crates/holochain_state/src/source_chain.rs Show resolved Hide resolved
crates/holochain_state/src/source_chain.rs Show resolved Hide resolved
crates/hdk/CHANGELOG.md Outdated Show resolved Hide resolved
@maackle maackle requested a review from neonphog July 13, 2022 22:30
Comment on lines +160 to +169

/// 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
}
Copy link
Contributor

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?

Copy link
Member Author

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

Copy link
Member Author

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.

Copy link
Contributor

@neonphog neonphog left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Copy link
Contributor

@freesig freesig left a 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.

maackle and others added 2 commits July 13, 2022 20:37
Co-authored-by: Stefan Junker <1181362+steveeJ@users.noreply.github.com>
@maackle maackle dismissed steveej’s stale review July 14, 2022 03:41

made the change requested

@maackle maackle enabled auto-merge July 14, 2022 03:47
@maackle maackle merged commit b60132c into develop Jul 14, 2022
@maackle maackle deleted the fix-query branch July 14, 2022 03:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants