From a2eccb8e837c1f16e785d2583f413efe0b6a61f5 Mon Sep 17 00:00:00 2001 From: Ashish Goswami Date: Wed, 8 Jul 2020 14:07:23 +0530 Subject: [PATCH] Fix alpha start in ludicrous mode (#5642) 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 d3c16be7531a763fbbb0a2597260d5ea59fee9b3) --- worker/draft.go | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/worker/draft.go b/worker/draft.go index df3793ff007..906366c96ee 100644 --- a/worker/draft.go +++ b/worker/draft.go @@ -1157,8 +1157,9 @@ func (n *node) Run() { if span := otrace.FromContext(pctx.Ctx); span != nil { span.Annotate(nil, "Proposal found in CommittedEntries") } - if x.WorkerConfig.LudicrousMode { - // Assuming that there will be no error while proposing. + if x.WorkerConfig.LudicrousMode && len(proposal.Mutations.GetEdges()) > 0 { + // Assuming that there will be no error while applying. But this + // assumption is only made for data mutations and not schema mutations. n.Proposals.Done(proposal.Key, nil) } }