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

(dgraph/fix) (cherrypick-20.07) Fix alpha start in ludicrous mode (#5642) #5912

Merged
merged 2 commits into from
Jul 10, 2020

Conversation

ashish-goswami
Copy link
Contributor

@ashish-goswami ashish-goswami commented Jul 9, 2020

Fixes: #5601
Fixes: DGRAPH-1669

Currently we are unable to start alpha server in ludicrous mode, because of reasons explained
below.

Things we do at alpha start:

At start we insert dgraph.type, dgraph.graphql.schema and dgraph.graphql.xid predicates as
our initial schema.
We also insert dgraph.graphql type(having predicates dgraph.graphql.schema and
dgraph.graphql.xid) as initial types.
We also upsert data related to graphql schema(which results in upserts for predicates
dgraph.graphql.schema and dgraph.graphql.xid).
While inserting types we verify that predicates used in the types should either already be present
in schema or should be part of same mutation where we are trying to insert this type.

In ludicrous mode we mark any proposal done without error as soon as it is retrieved as part of commited entries, as opposed to after applying proposal (this is done in normal mode).

Events which led to alpha getting stuck:

We propose schema mutation for dgraph.type, which is marked as done immediately. This
proposal is still getting applied.
Since we marked above proposal done without error, we propose next schema mutation for
dgraph.graphql.schema, which again is marked done without error. But applying of this proposal
fails as indexing was already in progress for dgraph.type. But we never retry this schema
mutation.
Next we propose dgraph.graphql.xid, which is applied successfully(indexing is done until now
for dgraph.type).
When we insert dgraph.graphql type, verifyTypes() fails, because it never finds
dgraphq.graphql.schema predicate.
Proposed solution:
Assumption that proposal is never failed while applying, hence it should be marked as done without
error immediately, should hold only for data mutations and not schema mutations.

This PR checks if proposal is data mutation(having edges > 0), while marking it done
immediately. This leads to retrying of schema proposal if they fail once because indexing is already
in progress.

Note: We didn't observe this before commit(aef7072), because predicate dgraph.graphql.schema was getting inserted via graphql upserts(#3 of start steps). Now after
commit(aef7072) we cannot insert data for predicates starting with dgraph. prefix unless those are already present.

(cherry picked from commit d3c16be)


This change is Reviewable

Docs Preview: Dgraph Preview

Fixes: #5601
Fixes: DGRAPH-1669

Currently we are unable to start alpha server in ludicrous mode, because of reasons explained
below.

Things we do at alpha start:

At start we insert dgraph.type, dgraph.graphql.schema and dgraph.graphql.xid predicates as
our initial schema.
We also insert dgraph.graphql type(having predicates dgraph.graphql.schema and
dgraph.graphql.xid) as initial types.
We also upsert data related to graphql schema(which results in upserts for predicates
dgraph.graphql.schema and dgraph.graphql.xid).
While inserting types we verify that predicates used in the types should either already be present
in schema or should be part of same mutation where we are trying to insert this type.

In ludicrous mode we mark any proposal done without error as soon as it is retrieved as part of commited entries, as opposed to after applying proposal (this is done in normal mode).

Events which led to alpha getting stuck:

We propose schema mutation for dgraph.type, which is marked as done immediately. This
proposal is still getting applied.
Since we marked above proposal done without error, we propose next schema mutation for
dgraph.graphql.schema, which again is marked done without error. But applying of this proposal
fails as indexing was already in progress for dgraph.type. But we never retry this schema
mutation.
Next we propose dgraph.graphql.xid, which is applied successfully(indexing is done until now
for dgraph.type).
When we insert dgraph.graphql type, verifyTypes() fails, because it never finds
dgraphq.graphql.schema predicate.
Proposed solution:
Assumption that proposal is never failed while applying, hence it should be marked as done without
error immediately, should hold only for data mutations and not schema mutations.

This PR checks if proposal is data mutation(having edges > 0), while marking it done
immediately. This leads to retrying of schema proposal if they fail once because indexing is already
in progress.

Note: We didn't observe this before commit(aef7072), because predicate dgraph.graphql.schema was getting inserted via graphql upserts(#3 of start steps). Now after
commit(aef7072) we cannot insert data for predicates starting with dgraph. prefix unless those are already present.

(cherry picked from commit d3c16be)
Copy link
Contributor

@harshil-goel harshil-goel left a comment

Choose a reason for hiding this comment

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

Reviewed 1 of 1 files at r1.
Reviewable status: :shipit: complete! all files reviewed, all discussions resolved (waiting on @manishrjain and @vvbalaji-dgraph)

@ashish-goswami ashish-goswami merged commit 643b907 into release/v20.07 Jul 10, 2020
@ashish-goswami ashish-goswami deleted the ashish/ludi-gql-cp branch July 10, 2020 16:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants