Next

Problem to solve

We have a range of timeout values defined in GitalyClient. One of these values is no_timeout. There is an issue with no_timeout, as some calls have been known to hang forever (see https://gitlab.com/gitlab-org/gitlab-ce/issues/53704).

no_timeout currently will become the default timeout for a Gitaly call from a Sidekiq worker if no timeout: argument was passed to Gitaly.call.

Proposal

• Replace Gitaly.no_timeout with a very high timeout value. All cases of Gitaly.no_timeout in the app should use this new high timeout instead. This new high timeout value will be called slow_timeout

Up for discussion

Note: These were the initial set of questions, however, please read the discussions in this Issue as some answers are being formed there.

• Should the default timeout for Sidekiq jobs become the same as for non-Sidekiq calls? Or,
• Should there be a new user-configurable default timeout created for Sidekiq jobs? (a gitaly_timeout_worker_default), or
• Should the default timeout for Sidekiq jobs become slow_timeout
• Should slow_timeout be set to 24 hours?

Documentation

To be updated:

• api/settings docs
• app/views/admin/application_settings/_gitaly.html.haml