GoExecutor should not return succ by default when completeness not eq 100

[Crazyinging]

As shown, GoExecutor return succ when completeness not eq 100. So it seems that the data received by the caller has the same effect as the missing data!
Reference: https://discuss.nebula-graph.com.cn/t/topic/1005

[Crazyinging]

I think GoExecutor should return an exception when completeness not eq 100. And before that, graphd can retry some times on the failed storageds.

To be smarter, after reading the code, I think maybe it can be changed like this:

1. GraphService add interface:

future_execute(int64_t sessionId, const std::string& stmt, const RequestConf& req_conf);

This interface will deal req_conf and call future_execute(int64_t sessionId, const std::string& stmt);

2. Add:

class RequestConfig {
  private:
    int32_t graphd_retry_times_;   // Value range 0-3. Default is 0.
                                   // Indicates the number of retries from graphd to storaged.
    bool require_full_data_;       // When graphd can not get the full amount of data, whether to return exception or return the partial data that has been obtained. 
                                   // True(Default value): return exception when can not get the full amount of data. 
                                   // False: return the partial data that has been obtained.
};

3. When GoExecutor::stepOut or GoExecutor::fetchVertexProps call storaged failed, retry according to RequestConfig.

[Crazyinging]

Correspondingly, I use java client and java client's GraphClient should add new interface:

public ResultSet executeQuery(String statement, RequestConfig requestConfig)
            throws ConnectionException, NGQLException, TException;

[dangleptr]

Do we really need the configuration is on request level?

[Crazyinging]

Do we really need the configuration is on request level?

Indeed, the request level may be over-designed.
Client level maybe be better, register RequestConfig when new client.

In addition, server level may not appropriate, such as adding configuration in the file nebula-graphd.conf, because the same service will have many users, and everyone's demands for stability may be different.

[CPWstatic]

This won't be fixed in nebula1.0. We had a configuration for it now in nebula2.0.