To fix this the `gitlab_rails['webhook_timeout']` value must be increased
To fix this the `gitlab_rails['webhook_timeout']` value must be increased
in the `gitlab.rb` config file, followed by the [`gitlab-ctl reconfigure` command](../administration/restart_gitlab.md).
in the `gitlab.rb` config file, followed by the [`gitlab-ctl reconfigure` command](../administration/restart_gitlab.md).
If you don't find the errors above, but do find *duplicate* entries like below (in `/var/log/gitlab/gitlab-rail`), this
If you don't find the errors above, but do find *duplicate* entries like below (in `/var/log/gitlab/gitlab-rail`), this
could also indicate that [webhook requests are timing out](../user/project/integrations/webhooks.md#receiving-duplicate-or-multiple-webhook-requests-triggered-by-one-event):
could also indicate that [webhook requests are timing out](../user/project/integrations/webhooks.md#webhook-fails-or-multiple-webhook-requests-are-triggered):
> **Note**: `assignee` and `assignee_id` keys are deprecated and now show the first assignee only.
NOTE: `assignee` and `assignee_id` keys are deprecated and now show the first assignee only.
### Comment events
### Comment events
Triggered when a new comment is made on commits, merge requests, issues, and code snippets.
Triggered when a new comment is made on commits, merge requests, issues, and code snippets.
The note data is stored in `object_attributes` (e.g. `note`,`noteable_type`). The
The note data is stored in `object_attributes` (for example, `note` or`noteable_type`). The
payload also includes information about the target of the comment. For example,
payload also includes information about the target of the comment. For example,
a comment on an issue includes the specific issue information under the `issue` key.
a comment on an issue includes the specific issue information under the `issue` key.
Valid target types:
Valid target types:
...
@@ -734,7 +734,7 @@ X-Gitlab-Event: Note Hook
...
@@ -734,7 +734,7 @@ X-Gitlab-Event: Note Hook
}
}
```
```
> **Note**: `assignee_id` field is deprecated and now shows the first assignee only.
NOTE: `assignee_id` field is deprecated and now shows the first assignee only.
#### Comment on code snippet
#### Comment on code snippet
...
@@ -1531,29 +1531,36 @@ You can find records for last 2 days in "Recent Deliveries" section on the edit
...
@@ -1531,29 +1531,36 @@ You can find records for last 2 days in "Recent Deliveries" section on the edit
In this section you can see HTTP status code (green for 200-299 codes, red for the others, `internal error` for failed deliveries ), triggered event, a time when the event was called, elapsed time of the request.
In this section you can see:
- HTTP status code (green for `200-299` codes, red for the others, `internal error` for failed deliveries).
- Triggered event.
- A time when the event was called.
- Elapsed time of the request.
If you need more information about execution, you can click `View details` link.
If you need more information about execution, you can click `View details` link.
On this page, you can see data that GitLab sends (request headers and body) and data that it received (response headers and body).
On this page, you can see data that GitLab sends (request headers and body) and data that it received (response headers and body).
From this page, you can repeat delivery with the same data by clicking `Resend Request` button.
From this page, you can repeat delivery with the same data by clicking `Resend Request` button.
NOTE:**Note:**
NOTE:
If URL or secret token of the webhook were updated, data is delivered to the new address.
If URL or secret token of the webhook were updated, data is delivered to the new address.
### Receiving duplicate or multiple webhook requests triggered by one event
### Webhook fails or multiple webhook requests are triggered
When GitLab sends a webhook, it expects a response in 10 seconds (set default value). If it does not receive one, it retries the webhook.
When GitLab sends a webhook, it expects a response in 10 seconds by default. If it does not receive
If the endpoint doesn't send its HTTP response within those 10 seconds, GitLab may decide the hook failed and retry it.
one, it retries the webhook. If the endpoint doesn't send its HTTP response within those 10 seconds,
GitLab may decide the hook failed and retry it.
If you are receiving multiple requests, you can try increasing the default value to wait for the HTTP response after sending the webhook
If your webhooks are failing or you are receiving multiple requests, you can try changing the
by uncommenting or adding the following setting to your `/etc/gitlab/gitlab.rb`:
default value. You can do this by uncommenting or adding the following setting to your
`/etc/gitlab/gitlab.rb` file:
```ruby
```ruby
gitlab_rails['webhook_timeout']=10
gitlab_rails['webhook_timeout']=10
```
```
### Troubleshooting: "Unable to get local issuer certificate"
### Unable to get local issuer certificate
When SSL verification is enabled, this error indicates that GitLab isn't able to verify the SSL certificate of the webhook endpoint.
When SSL verification is enabled, this error indicates that GitLab isn't able to verify the SSL certificate of the webhook endpoint.
Typically, this is because the root certificate isn't issued by a trusted certification authority as
Typically, this is because the root certificate isn't issued by a trusted certification authority as
...
@@ -1584,7 +1591,7 @@ end
...
@@ -1584,7 +1591,7 @@ end
server.start
server.start
```
```
Pick an unused port (e.g. 8000) and start the script: `ruby print_http_body.rb
Pick an unused port (for example, `8000`) and start the script: `ruby print_http_body.rb
8000`. Then add your server as a webhook receiver in GitLab as
8000`. Then add your server as a webhook receiver in GitLab as
