starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

Data too long for column `info_json` when monitoring cloudfunctions.net Endpoints #3590

New issue

Closed

opened 2026-02-28 03:34:35 -05:00 by deekerman · 3 comments

deekerman commented

2026-02-28 03:34:35 -05:00

Owner

Originally created by @David-Development on GitHub (Sep 4, 2024).

🛡️ Security Policy

I agree to have read this project Security Policy

Description

When monitoring Google cloudfunctions ER_DATA_TOO_LONG errors are thrown in the logs and no Certificate Expiry dates are shown.

👟 Reproduction steps

Any fake cloudfunction url does the trick for testing even though it returns 404 - Like: https://abc.cloudfunctions.net/

👀 Expected behavior

No errors in the logs / Certificate Expiry etc. are displayed correctly. Considering that the JSON it's trying to save has a significant amount of characters it probably makes sense to strip some infos from it..?

😓 Actual Behavior

No certificate expiry date is visible / errors are shown in logs

🐻 Uptime-Kuma Version

2.0.0-dev

💻 Operating System and Arch

Docker

🌐 Browser

Google Chrome 128.0.6613.114

🖥️ Deployment Environment

Runtime: Docker
Database: MariaDB 11.4.3
Filesystem used to store the database on: HDD
number of monitors: 5

📝 Relevant log output

uptime-kuma    |   code: 'ER_DATA_TOO_LONG',
uptime-kuma    |   errno: 1406,
uptime-kuma    |   sqlState: '22001',
uptime-kuma    |   sqlMessage: "Data too long for column 'info_json' at row 1",
uptime-kuma    |   sql: 'insert into `monitor_tls_info` (`info_json`, `monitor_id`) values (\'{\\"valid\\":true,\\"certInfo\\":{\\"subject\\":{\\"CN\\":\\"misc.google.com\\"},\\"issuer\\":{\\"C\\":\\"US\\",\\"O\\":\\"Google Trust Services\\",\\"CN\\":\\"WR2\\"},\\"subjectaltname\\":\\"DNS:misc.google.com, DNS:*.actions.google.com, 
....
:EC:'... 60832 more characters
uptime-kuma    | }

Originally created by @David-Development on GitHub (Sep 4, 2024). ### 📑 I have found these related issues/pull requests - ### 🛡️ Security Policy - [X] I agree to have read this project [Security Policy](https://github.com/louislam/uptime-kuma/security/policy) ### Description When monitoring Google cloudfunctions `ER_DATA_TOO_LONG` errors are thrown in the logs and no Certificate Expiry dates are shown. ### 👟 Reproduction steps Any fake cloudfunction url does the trick for testing even though it returns 404 - Like: https://abc.cloudfunctions.net/ ### 👀 Expected behavior No errors in the logs / Certificate Expiry etc. are displayed correctly. Considering that the JSON it's trying to save has a significant amount of characters it probably makes sense to strip some infos from it..? ### 😓 Actual Behavior No certificate expiry date is visible / errors are shown in logs ### 🐻 Uptime-Kuma Version 2.0.0-dev ### 💻 Operating System and Arch Docker ### 🌐 Browser Google Chrome 128.0.6613.114 ### 🖥️ Deployment Environment - Runtime: Docker - Database: MariaDB 11.4.3 - Filesystem used to store the database on: HDD - number of monitors: 5 ### 📝 Relevant log output ```shell uptime-kuma | code: 'ER_DATA_TOO_LONG', uptime-kuma | errno: 1406, uptime-kuma | sqlState: '22001', uptime-kuma | sqlMessage: "Data too long for column 'info_json' at row 1", uptime-kuma | sql: 'insert into `monitor_tls_info` (`info_json`, `monitor_id`) values (\'{\\"valid\\":true,\\"certInfo\\":{\\"subject\\":{\\"CN\\":\\"misc.google.com\\"},\\"issuer\\":{\\"C\\":\\"US\\",\\"O\\":\\"Google Trust Services\\",\\"CN\\":\\"WR2\\"},\\"subjectaltname\\":\\"DNS:misc.google.com, DNS:*.actions.google.com, .... :EC:'... 60832 more characters uptime-kuma | } ```

deekerman

2026-02-28 03:34:35 -05:00

closed this issue
added the
bug
label

deekerman commented

2026-02-28 03:34:42 -05:00

Author

Owner

@louislam commented on GitHub (Sep 5, 2024):

Thanks for the report. I think we have to review all VARCHAR/TEXT fields.

@louislam commented on GitHub (Sep 5, 2024): Thanks for the report. I think we have to review all VARCHAR/TEXT fields.

deekerman commented

2026-02-28 03:34:42 -05:00

Author

Owner

@Abhay2133 commented on GitHub (Oct 2, 2024):

I’m eager to contribute to this issue and have already run it locally. I've even fixed it by manually changing the database schema. Could you assign it to me?

@Abhay2133 commented on GitHub (Oct 2, 2024): I’m eager to contribute to this issue and have already run it locally. I've even fixed it by manually changing the database schema. Could you assign it to me?

deekerman commented

2026-02-28 03:34:42 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Oct 2, 2024):

We don't assign people to issues. Firstly, because only contributors and the issue createe can be assigned and we don't believe that the bureaucracy adds value.

Feel free to contribute a fix.
Also make sure that

existing collumns create before any migration and
the insertion into that collumn is are handled correctly

@CommanderStorm commented on GitHub (Oct 2, 2024): We don't assign people to issues. Firstly, because only contributors and the issue createe can be assigned and we don't believe that the bureaucracy adds value. Feel free to contribute a fix. Also make sure that - existing collumns create before any migration and - the insertion into that collumn is are handled correctly