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

Allow redeployment of grafted subgraph even when graft_base is not available #4695

Merged
merged 4 commits into from
Jun 21, 2023

Conversation

incrypto32
Copy link
Member

Closes #4534

@incrypto32 incrypto32 force-pushed the incrypto32/graft-redeploy-fix branch 2 times, most recently from fd791dd to 8d2ca4d Compare June 14, 2023 06:35
@incrypto32 incrypto32 marked this pull request as ready for review June 14, 2023 06:40
@incrypto32 incrypto32 changed the title redeployment of grafted subgraph even when graft_base is not available Allow redeployment of grafted subgraph even when graft_base is not available Jun 14, 2023
@incrypto32 incrypto32 force-pushed the incrypto32/graft-redeploy-fix branch from 8d2ca4d to 6ea0edf Compare June 14, 2023 15:43
@incrypto32 incrypto32 requested a review from tilacog June 14, 2023 15:44
@incrypto32 incrypto32 force-pushed the incrypto32/graft-redeploy-fix branch from 6ea0edf to a54409d Compare June 14, 2023 15:44
@incrypto32 incrypto32 self-assigned this Jun 15, 2023
@@ -1441,6 +1441,11 @@ impl DeploymentStore {
.await
}

pub(crate) fn exists(&self, id: Arc<Site>) -> Result<bool, StoreError> {
let conn = self.get_conn()?;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Lets use with_conn here to make this async.

Copy link
Member Author

Choose a reason for hiding this comment

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

@leoyvens i tried that initially wouldn't that mean i would have to make all the callers also async function to await on it?

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 was unsure if i should do that, let me know if its ok.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Are there any non-async callers? If there are then we'd need to keep this one and add an async version.

Copy link
Member Author

Choose a reason for hiding this comment

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

fn create_deployment_internal is not async but its callers can be made async ( cause callers all the way is async ). Should i make them all async in that case?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I see now that this is a bigger problem since fn create_deployment_internal is doing many sync DB operations, but is called from an async context. Ok we can leave this exists as sync for now, and later find a solution for the whole function.

layout.site.schema_version
} else {
DeploymentSchemaVersion::LATEST
};
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think we could avoid the need for a schema_version variable here by having fn allocate_site take a graft_base parameter instead of schema_version, and do the logic there.

fn allocate_site already checks for existence, and if it needs to search for the graft base I believe it could use fn find_active_site.

Copy link
Member Author

Choose a reason for hiding this comment

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

got it, will make that change

raw,
resolver,
logger,
ENV_VARS.max_spec_version.clone(),
)
.map_err(SubgraphRegistrarError::ResolveError)
.await?;

let exists = store.is_deployed(&deployment)?;
Copy link
Collaborator

Choose a reason for hiding this comment

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

There is an fn graft_pending which we perhaps should additionally check, because it checks if the subgraph has actually finished the graft process. It would be nice if we were able to use that here.

@incrypto32 incrypto32 requested a review from leoyvens June 19, 2023 15:26
@incrypto32 incrypto32 force-pushed the incrypto32/graft-redeploy-fix branch from dde11bc to 8ccd608 Compare June 20, 2023 11:11
@incrypto32
Copy link
Member Author

Integration tests, failing.. checking it out.

@incrypto32 incrypto32 force-pushed the incrypto32/graft-redeploy-fix branch from 8ccd608 to 5062fe8 Compare June 20, 2023 14:27
Copy link
Collaborator

@leoyvens leoyvens left a comment

Choose a reason for hiding this comment

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

Looks great! Thanks for bearing with the reviews

Ok(graft_pending) => graft_pending,
Err(StoreError::DeploymentNotFound(_)) => true,
Err(e) => return Err(SubgraphRegistrarError::StoreError(e)),
};
Copy link
Collaborator

Choose a reason for hiding this comment

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

Would be great to have comments here.

@@ -1247,18 +1247,33 @@ impl<'a> Connection<'a> {
}

/// Create a site for a brand new deployment.
/// If it already exists, return the existing site.
/// and a boolean indicating whether a new site was created.
/// false means the site already existed.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Nice comment, just need to check ponctuation and capitalization.

Copy link
Member Author

Choose a reason for hiding this comment

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

ah thanks for catching that. I'll fix that

@incrypto32 incrypto32 force-pushed the incrypto32/graft-redeploy-fix branch from f999321 to c73fc91 Compare June 20, 2023 16:18
// Determine if the subgraph should be validated.
// Validate the subgraph if there is a pending graft, indicating the presence of a graft base.
// If the subgraph is new (DeploymentNotFound), it should also be validated.
// If the subgraph already exists and there is no pending graft, validation is not required.
Copy link
Collaborator

Choose a reason for hiding this comment

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

The wording here is not very precise, this boolean is not deciding if the whole subgraph should be validated, but if the graft base should be validated.

Copy link
Member Author

Choose a reason for hiding this comment

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

// Determine if the graft_base should be validated.
// Validate the graft_base if there is a pending graft, ensuring its presence.
// If the subgraph is new (indicated by DeploymentNotFound), the graft_base should be validated.
// If the subgraph already exists and there is no pending graft, graft_base validation is not required.

@leoyvens how does this look?

@incrypto32 incrypto32 force-pushed the incrypto32/graft-redeploy-fix branch from c73fc91 to f275665 Compare June 21, 2023 05:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 🚗 Merged
Development

Successfully merging this pull request may close these issues.

[Feature] Allow redeployment of grafted subgraphs even if the graft base is not found
3 participants