[GH-ISSUE #947] Healthchecks Update Results in 'badly formed hexadecimal UUID string' Error

kerem commented

2026-02-25 23:43:12 +03:00

Owner

Originally created by @jimmybrancaccio on GitHub (Jan 24, 2024).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/947

Hello Team,

It looks like my Healthchecks instance updated to the latest 3.x release. I actually hadn't realized this so that was my fault. That said, when I tried logging into my instance today it started to fail. I enabled debugging and saw the below message in my logs. I am using the Docker image healthchecks/healthchecks:latest. I didn't change any environment variables between the last 2.x version and now (except to enable debugging).

From the Docker container logs I am seeing:

Internal Server Error: /
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/django/core/handlers/exception.py", line 55, in inner
    response = get_response(request)
               ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/core/handlers/base.py", line 197, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/healthchecks/hc/front/views.py", line 367, in index
    projects = list(q)
               ^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/db/models/query.py", line 398, in __iter__
    self._fetch_all()
  File "/usr/local/lib/python3.11/site-packages/django/db/models/query.py", line 1926, in _fetch_all
    self._result_cache = list(self._iterable_class(self))
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/db/models/query.py", line 121, in __iter__
    for row in compiler.results_iter(results):
  File "/usr/local/lib/python3.11/site-packages/django/db/models/sql/compiler.py", line 1500, in apply_converters
    value = converter(value, expression, connection)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/db/backends/mysql/operations.py", line 336, in convert_uuidfield_value
    value = uuid.UUID(value)
            ^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/uuid.py", line 178, in __init__
    raise ValueError('badly formed hexadecimal UUID string')
ValueError: badly formed hexadecimal UUID string

It looks like I may have missed a migration in MySQL? I did check through the release notes but didn't see anything that was necessary to do manually when upgrading to a 3.x release - though it's possible I missed something and I apologize about that. I also checked the issues in GitHub but didn't see anyone else reporting this (yay lucky me!).

Of note, I also saw this message when the container was being started up and I did perform it's recommended actions:

Running migrations:
  No migrations to apply.
  Your models in app(s): 'api' have changes that are not yet reflected in a migration, and so won't be applied.
  Run 'manage.py makemigrations' to make new migrations, and then re-run 'manage.py migrate' to apply them.

I did go into the container and I ran ./manage.py makemigrations and ./manage.py migrate. It did import them without issue. Oddly enough each time the container restarts or is created I get that same messaging about the api model not being reflected in a migration.

If anyone has any ideas on what I can do to resolve this it would be greatly appreciated. If any other information is needed to troubleshoot the problem please don't hesitate to let me know!

Thanks,

Originally created by @jimmybrancaccio on GitHub (Jan 24, 2024). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/947 Hello Team, It looks like my Healthchecks instance updated to the latest 3.x release. I actually hadn't realized this so that was my fault. That said, when I tried logging into my instance today it started to fail. I enabled debugging and saw the below message in my logs. I am using the Docker image `healthchecks/healthchecks:latest`. I didn't change any environment variables between the last 2.x version and now (except to enable debugging). From the Docker container logs I am seeing: ``` Internal Server Error: / Traceback (most recent call last): File "/usr/local/lib/python3.11/site-packages/django/core/handlers/exception.py", line 55, in inner response = get_response(request) ^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/django/core/handlers/base.py", line 197, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/healthchecks/hc/front/views.py", line 367, in index projects = list(q) ^^^^^^^ File "/usr/local/lib/python3.11/site-packages/django/db/models/query.py", line 398, in __iter__ self._fetch_all() File "/usr/local/lib/python3.11/site-packages/django/db/models/query.py", line 1926, in _fetch_all self._result_cache = list(self._iterable_class(self)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/django/db/models/query.py", line 121, in __iter__ for row in compiler.results_iter(results): File "/usr/local/lib/python3.11/site-packages/django/db/models/sql/compiler.py", line 1500, in apply_converters value = converter(value, expression, connection) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/django/db/backends/mysql/operations.py", line 336, in convert_uuidfield_value value = uuid.UUID(value) ^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/uuid.py", line 178, in __init__ raise ValueError('badly formed hexadecimal UUID string') ValueError: badly formed hexadecimal UUID string ``` It looks like I may have missed a migration in MySQL? I did check through the release notes but didn't see anything that was necessary to do manually when upgrading to a 3.x release - though it's possible I missed something and I apologize about that. I also checked the issues in GitHub but didn't see anyone else reporting this (yay lucky me!). Of note, I also saw this message when the container was being started up and I did perform it's recommended actions: ``` Running migrations: No migrations to apply. Your models in app(s): 'api' have changes that are not yet reflected in a migration, and so won't be applied. Run 'manage.py makemigrations' to make new migrations, and then re-run 'manage.py migrate' to apply them. ``` I did go into the container and I ran `./manage.py makemigrations` and `./manage.py migrate`. It did import them without issue. Oddly enough each time the container restarts or is created I get that same messaging about the api model not being reflected in a migration. If anyone has any ideas on what I can do to resolve this it would be greatly appreciated. If any other information is needed to troubleshoot the problem please don't hesitate to let me know! Thanks,

kerem closed this issue

2026-02-25 23:43:12 +03:00

kerem commented

2026-02-25 23:43:12 +03:00

Author

Owner

@cuu508 commented on GitHub (Jan 24, 2024):

Thanks for the report.

My initial guess is that this might have something to do with the upgrade to Django 5.0. (Django's handling of UUID fields changed in the 4.x -> 5.0 upgrade).

If you can, drop into the database shell and run the following query:

select id, code from accounts_project;

All code values should be UUIDs. See if there are any suspicious value (empty, or something other than an UUID).

@cuu508 commented on GitHub (Jan 24, 2024): Thanks for the report. My initial guess is that this might have something to do with the upgrade to Django 5.0. (Django's handling of UUID fields changed in the 4.x -> 5.0 upgrade). If you can, drop into the database shell and run the following query: select id, code from accounts_project; All `code` values should be UUIDs. See if there are any suspicious value (empty, or something other than an UUID).

kerem commented

2026-02-25 23:43:12 +03:00

Author

Owner

@jimmybrancaccio commented on GitHub (Jan 24, 2024):

Hi @cuu508,

I think you're definitely right. I actually started to dig into the database right after my post. I noticed the first project which didn't have any values in the name or owner_id columns. I updated that. I then noticed the badge_key value looked a little off so I tried to get that to work based on what other projects looked like. Here's what it looks like now, I formatted the output in JSON, I hope that's okay:

  {
    "id": 1,
    "code": "89d1d57c24bc42619c8b9751460a3b2c",
    "name": "Test",
    "api_key": "",
    "api_key_readonly": "",
    "owner_id": 1,
    "badge_key": "89d1d57c-24bc-4261-9c8b-9751460a3b2c",
    "ping_key": null,
    "show_slugs": 0
  }

Prior to this the badge_key value was 39ede81be00b4878a8f8975146. Unfortunately even after updating it I am still getting the same error -- badly formed hexadecimal UUID string.

@jimmybrancaccio commented on GitHub (Jan 24, 2024): Hi @cuu508, I think you're definitely right. I actually started to dig into the database right after my post. I noticed the first project which didn't have any values in the `name` or `owner_id` columns. I updated that. I then noticed the `badge_key` value looked a little off so I tried to get that to work based on what other projects looked like. Here's what it looks like now, I formatted the output in JSON, I hope that's okay: ```json { "id": 1, "code": "89d1d57c24bc42619c8b9751460a3b2c", "name": "Test", "api_key": "", "api_key_readonly": "", "owner_id": 1, "badge_key": "89d1d57c-24bc-4261-9c8b-9751460a3b2c", "ping_key": null, "show_slugs": 0 } ``` <img width="1156" alt="Screenshot 2024-01-24 at 12 54 24" src="https://github.com/healthchecks/healthchecks/assets/405585/a1ac761d-8158-45e8-9004-898b3d719c67"> Prior to this the `badge_key` value was `39ede81be00b4878a8f8975146`. Unfortunately even after updating it I am still getting the same error -- `badly formed hexadecimal UUID string`.

kerem commented

2026-02-25 23:43:12 +03:00

Author

Owner

@cuu508 commented on GitHub (Jan 24, 2024):

Try to format the UUID with dashes for the code column: 89d1d57c-24bc-4261-9c8b-9751460a3b2c.

@cuu508 commented on GitHub (Jan 24, 2024): Try to format the UUID with dashes for the `code` column: `89d1d57c-24bc-4261-9c8b-9751460a3b2c`.

kerem commented

2026-02-25 23:43:12 +03:00

Author

Owner

@jimmybrancaccio commented on GitHub (Jan 24, 2024):

Ok, I think we're getting a bit closer! Now it seems to be a user/profile issue from what I can understand.

Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/django/core/handlers/exception.py", line 55, in inner
    response = get_response(request)
               ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/core/handlers/base.py", line 197, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/healthchecks/hc/front/views.py", line 359, in index
    summary = _get_project_summary(request.profile)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/healthchecks/hc/front/views.py", line 341, in _get_project_summary
    for check in q:
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/db/models/query.py", line 398, in __iter__
    self._fetch_all()
    ^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/db/models/query.py", line 1926, in _fetch_all
    self._result_cache = list(self._iterable_class(self))
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/db/models/query.py", line 121, in __iter__
    for row in compiler.results_iter(results):
    ^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/db/models/sql/compiler.py", line 1500, in apply_converters
    value = converter(value, expression, connection)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/db/backends/mysql/operations.py", line 336, in convert_uuidfield_value
    value = uuid.UUID(value)
            ^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/uuid.py", line 178, in __init__
    raise ValueError('badly formed hexadecimal UUID string')
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Exception Type: ValueError at /
Exception Value: badly formed hexadecimal UUID string

@jimmybrancaccio commented on GitHub (Jan 24, 2024): Ok, I think we're getting a bit closer! Now it seems to be a user/profile issue from what I can understand. ``` Traceback (most recent call last): File "/usr/local/lib/python3.11/site-packages/django/core/handlers/exception.py", line 55, in inner response = get_response(request) ^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/django/core/handlers/base.py", line 197, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/healthchecks/hc/front/views.py", line 359, in index summary = _get_project_summary(request.profile) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/healthchecks/hc/front/views.py", line 341, in _get_project_summary for check in q: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/django/db/models/query.py", line 398, in __iter__ self._fetch_all() ^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/django/db/models/query.py", line 1926, in _fetch_all self._result_cache = list(self._iterable_class(self)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/django/db/models/query.py", line 121, in __iter__ for row in compiler.results_iter(results): ^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/django/db/models/sql/compiler.py", line 1500, in apply_converters value = converter(value, expression, connection) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/django/db/backends/mysql/operations.py", line 336, in convert_uuidfield_value value = uuid.UUID(value) ^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/uuid.py", line 178, in __init__ raise ValueError('badly formed hexadecimal UUID string') ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Exception Type: ValueError at / Exception Value: badly formed hexadecimal UUID string ```

kerem commented

2026-02-25 23:43:12 +03:00

Author

Owner

@jimmybrancaccio commented on GitHub (Jan 24, 2024):

Quick update, it's gotta be something in the 3.1 release. I changed first to 2.10 and that worked fine, then changed to 3.0.1 and that seems to be working fine.

@jimmybrancaccio commented on GitHub (Jan 24, 2024): Quick update, it's gotta be something in the 3.1 release. I changed first to 2.10 and that worked fine, then changed to 3.0.1 and that seems to be working fine.

kerem commented

2026-02-25 23:43:12 +03:00

Author

Owner

@jimmybrancaccio commented on GitHub (Jan 24, 2024):

Ok, I think I finally got it figured out. I looked at all the tables and anywhere there was a code column, I set the data type from CHAR(32) to UUID. Haven't hit any issues since then 😝

@jimmybrancaccio commented on GitHub (Jan 24, 2024): Ok, I think I finally got it figured out. I looked at all the tables and anywhere there was a `code` column, I set the data type from `CHAR(32)` to `UUID`. Haven't hit any issues since then 😝

kerem commented

2026-02-25 23:43:12 +03:00

Author

Owner

@cuu508 commented on GitHub (Jan 28, 2024):

Glad to hear you got it resolved!

Is this a reproducible issue? If you set up a fresh install with, say, 3.0.1, and upgrade to 3.1, do you run into the same issue?

@cuu508 commented on GitHub (Jan 28, 2024): Glad to hear you got it resolved! Is this a reproducible issue? If you set up a fresh install with, say, 3.0.1, and upgrade to 3.1, do you run into the same issue?

kerem commented

2026-02-25 23:43:12 +03:00

Author

Owner

@jimmybrancaccio commented on GitHub (Jan 28, 2024):

@cuu508 I believe it would only be reproducible if you started with MariaDB 10.6 or less. I am 99% sure when I originally installed Healthchecks I was using some version of MariaDB where the field code defaulted to char(32) (https://docs.djangoproject.com/en/5.0/ref/models/fields/#uuidfield), probably MariaDB 10.4.

Between when I originally installed Healthchecks and when it updated to v3.1, I've also updated to MariaDB 10.11 but the fields were never converted to uuid and have stayed as char(32).

I think, if possible, it would be good idea to add a check in there that checks to see if MariaDB 10.7+ is being used (or MySQL 8+ - I think that version supports the uuid data type), and if it is, then a migration runs to convert those code columns to use uuid as the data type.

@jimmybrancaccio commented on GitHub (Jan 28, 2024): @cuu508 I believe it would only be reproducible if you started with MariaDB 10.6 or less. I am 99% sure when I originally installed Healthchecks I was using some version of MariaDB where the field `code` defaulted to `char(32)` (https://docs.djangoproject.com/en/5.0/ref/models/fields/#uuidfield), probably MariaDB 10.4. Between when I originally installed Healthchecks and when it updated to v3.1, I've also updated to MariaDB 10.11 but the fields were never converted to `uuid` and have stayed as `char(32)`. I think, if possible, it would be good idea to add a check in there that checks to see if MariaDB 10.7+ is being used (or MySQL 8+ - I think that version supports the `uuid` data type), and if it is, then a migration runs to convert those `code` columns to use `uuid` as the data type.

kerem commented

2026-02-25 23:43:12 +03:00

Author

Owner

@cuu508 commented on GitHub (Feb 3, 2024):

I think this is the same issue as #929

@cuu508 commented on GitHub (Feb 3, 2024): I think this is the same issue as #929

Rows
Columns

[GH-ISSUE #947] Healthchecks Update Results in 'badly formed hexadecimal UUID string' Error #664