UpdateHookTask MySQL database error #3569

New Issue

GiteaMirror · 2025-11-02T05:17:38-06:00

GiteaMirror commented

2025-11-02 05:17:38 -06:00

Originally created by @beppler on GitHub (Jul 10, 2019).

Gitea version (or commit ref): 1.8.3
Git version: 2.20.1
Operating system: Debian 10
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:

Description

Some of our webhooks are generating the following error on logs.

2019/07/10 17:01:06 [...ea/models/webhook.go:718 deliver()] [E] UpdateHookTask [2502]: Error 1406: Data too long for column 'response_content' at row 1

This is happening because the column reponse_content of the table hook_taskis of type TEXT on MySQL (and MariaDB) that is limited to 16K characters.

Can it be altered to the type MEDIUMTEXT (that is limited to 16M characters) or LONGTEXT (that is limited to 4GB characters)?

Tha same may be applied to the request_content column on the same table.

...

Originally created by @beppler on GitHub (Jul 10, 2019). - Gitea version (or commit ref): 1.8.3 - Git version: 2.20.1 - Operating system: Debian 10 - Database (use `[x]`): - [ ] PostgreSQL - [X] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [X] Not relevant - Log gist: ## Description Some of our webhooks are generating the following error on logs. 2019/07/10 17:01:06 [...ea/models/webhook.go:718 deliver()] [E] UpdateHookTask [2502]: Error 1406: Data too long for column 'response_content' at row 1 This is happening because the column `reponse_content` of the table `hook_task`is of type `TEXT` on MySQL (and MariaDB) that is limited to 16K characters. Can it be altered to the type `MEDIUMTEXT` (that is limited to 16M characters) or `LONGTEXT` (that is limited to 4GB characters)? Tha same may be applied to the `request_content` column on the same table. ...

GiteaMirror closed this issue

2025-11-02 05:17:38 -06:00

GiteaMirror commented

2025-11-02 05:17:39 -06:00

@lunny commented on GitHub (Jul 11, 2019):

xorm Sync will not change a column size from bigger to smaller, So I think you are safe to do that. But that will display a wanning log when gitea start.

@lunny commented on GitHub (Jul 11, 2019): `xorm` Sync will not change a column size from bigger to smaller, So I think you are safe to do that. But that will display a wanning log when gitea start.

GiteaMirror commented

2025-11-02 05:17:39 -06:00

@beppler commented on GitHub (Jul 11, 2019):

I changed column type on both columns and the warning appears.

Maybe a new migration can be added to resolve this problem.

@beppler commented on GitHub (Jul 11, 2019): I changed column type on both columns and the warning appears. Maybe a new migration can be added to resolve this problem.

GiteaMirror commented

2025-11-02 05:17:39 -06:00

@mrsdizzie commented on GitHub (Jul 11, 2019):

Hmm I don't think this is a problem in Gitea -- Gitea would never generate a request_content close to the 64k limit of TEXT for Webhook content and if something is sending a response larger than that it very likely means somebody has configured the wrong URL or there is another problem with the receiving script output.

Most Web hook response should just be HTML status/headers/and maybe a body that says "ok" or something small. TEXT should be fine for that.

TEXT will hold about 65,000 char (64kb) and for context an average response from Discord/Slack and similar is about 500-600 char depending on the headers. Gitea request_content is under 100 char on avarage.

Based on content from Discord chat it sounds like somebody did configure the wrong Webhook URL in this case, and I think it is right that we don't store the very large response. If somebody configures something wrong or a script is misbehaving it shouldn't be able to store up to 16MB (or 4GB) in the database for each hook event.

@mrsdizzie commented on GitHub (Jul 11, 2019): Hmm I don't think this is a problem in Gitea -- Gitea would never generate a request_content close to the 64k limit of TEXT for Webhook content and if something is sending a response larger than that it very likely means somebody has configured the wrong URL or there is another problem with the receiving script output. Most Web hook response should just be HTML status/headers/and maybe a body that says "ok" or something small. TEXT should be fine for that. TEXT will hold about 65,000 char (64kb) and for context an average response from Discord/Slack and similar is about 500-600 char depending on the headers. Gitea request_content is under 100 char on avarage. Based on content from Discord chat it sounds like somebody did configure the wrong Webhook URL in this case, and I think it is right that we don't store the very large response. If somebody configures something wrong or a script is misbehaving it shouldn't be able to store up to 16MB (or 4GB) in the database for each hook event.

GiteaMirror commented

2025-11-02 05:17:39 -06:00

@beppler commented on GitHub (Jul 12, 2019):

Yes I found the culprit and it was a bad webhook url.

I will close the issue.

Thanks for your assistance.

@beppler commented on GitHub (Jul 12, 2019): Yes I found the culprit and it was a bad webhook url. I will close the issue. Thanks for your assistance.

GiteaMirror referenced this issue

2025-11-02 12:23:59 -06:00

[PR #3569] [MERGED] Fix the protected branch panic issue (#3567) #17002

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#3569