{"push_id":1525667133,"size":1,"distinct_size":1,"ref":"refs/heads/release-branch.v3","head":"448e5f4a85ca197923e7ee49ee6b042d3f8022e4","before":"016ed1792360a96603f0f16e7d28fd7d9a0306b8","commits":[{"sha":"448e5f4a85ca197923e7ee49ee6b042d3f8022e4","author":{"name":"Oliver Eilhard","email":"ef9ba0168dba9394d476778eb98d9d3b8e35edbe@eilhard.net"},"message":"Add Retrier to intercept failed requests\n\nThe Retrier allows users to intercept failed requests. The Retrier\ninterface specifies a single Retry func with the following\nsignature:\n\n    Retry(\n      ctx context.Context,\n      retry int,\n      request *http.Request,\n      response *http.Response,\n      err error,\n    ) (time.Duration, bool, error)\n\nRetry can inspect the parameters to decide whether to retry or not.\nE.g. the retry parameter is the number of retries already processed.\nNotice that request and response may be nil. The err parameter is the\nerror returned from Elasticsearch or the HTTP client.\n\nIf elastic should retry calling Elasticsearch, Retry must return a\nduration to wait for the next request and true. It can use a\nbackoff strategy to do so (see below).\n\nIf elastic should stop calling Elasticsearch, Retry must return\nfalse as the 2nd return value.\n\nIf Retry wants to stop and return a custom error, it can do so\nby returning a non-nil error as the 3rd return value.\n\nTo simplify the implementation of custom Retriers, elastic comes with\na number of backoff implementations (see backoff.go). There is e.g.\nan ExponentialBackoff or a ConstantBackoff implementation.\n\nSee the project wiki for further information about Retriers.","distinct":true,"url":"https://api.github.com/repos/olivere/elastic/commits/448e5f4a85ca197923e7ee49ee6b042d3f8022e4"}]}
{"actor":{"display_login":"olivere"}}