Querying the `text_log_error` table for those ids shows there to be junk values in its `line` field. There appear to be two issues here: 1. `mysqlclient-python`'s behaviour differs depending on Python version - under Python 3 it defaults `use_unicode` to `True`, which means it attempts to decode the `line` field but fails (since it doesn't use `'replace'` or `'ignore'`). This seems like something that the Django ORM should try to protect against (eg by setting `use_unicode` to the same value on all Python versions and handling the unicode conversion itself), given it generally handles any implementation differences in layers lower than the ORM. 2. the `UnicodeDecodeError` is occurring for a field (`text_log_error.line`) that is not actually needed for the `.delete()` (it's not a primary key etc), so Django shouldn't be fetching that field regardless when making the `text_log_error` `SELECT` query (Plus ideally Django would support cascade deletes, so we wouldn't need to use the current `.delete()` approach; [https://code.djangoproject.com/ticket/21961 ticket 21961]) Fixing issue (2) would presumably also improve `.delete()` performance. I've filed a ticket against Django: https://code.djangoproject.com/ticket/30191 ...though I doubt it's something that will get fixed either at all, or in time to help us - so I'll come up with a workaround for now. Regarding the junk `line` values themselves - they are from logs parsed when using Python 2.7 and prior to https://github.com/mozilla/treeherder/commit/4bdf9f91018b3a3306bf78db947a512f24225bab . I'm presuming with that change in place and/or once switched to Python 3, we won't have any more being inserted, but we'll at least need to handle them in cycle_data until 4 months have passed so they've all expired.
Bug 1528710 Comment 1 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Querying the `text_log_error` table for those ids shows there to be junk values in its `line` field. There appear to be two issues here: 1. `mysqlclient-python`'s behaviour differs depending on Python version - under Python 3 it defaults `use_unicode` to `True`, which means it attempts to decode the `line` field but fails (since it doesn't use `'replace'` or `'ignore'`). This seems like something that the Django ORM should try to protect against (eg by setting `use_unicode` to the same value on all Python versions and handling the unicode conversion itself), given it generally handles any implementation differences in layers lower than the ORM. 2. the `UnicodeDecodeError` is occurring for a field (`text_log_error.line`) that is not actually needed for the `.delete()` (it's not a primary key etc), so Django shouldn't be fetching that field regardless when making the `text_log_error` `SELECT` query (Plus ideally Django would support cascade deletes, so we wouldn't need to use the current `.delete()` approach - https://code.djangoproject.com/ticket/21961) I've filed a ticket against Django: https://code.djangoproject.com/ticket/30191 ...though I doubt it's something that will get fixed either at all, or in time to help us - so I'll come up with a workaround for now. Regarding the junk `line` values themselves - they are from logs parsed when using Python 2.7 and prior to https://github.com/mozilla/treeherder/commit/4bdf9f91018b3a3306bf78db947a512f24225bab . I'm presuming with that change in place and/or once switched to Python 3, we won't have any more being inserted, but we'll at least need to handle them in cycle_data until 4 months have passed so they've all expired.
Querying the `text_log_error` table for those ids shows there to be junk values in its `line` field. There appear to be two issues here: 1. `mysqlclient-python`'s behaviour differs depending on Python version - under Python 3 it defaults `use_unicode` to `True`, which means it attempts to decode the `line` field but fails (since it doesn't use `'replace'` or `'ignore'`). This seems like something that the Django ORM should try to protect against (eg by setting `use_unicode` to the same value on all Python versions and handling the unicode conversion itself), given it generally handles any implementation differences in layers lower than the ORM. 2. the `UnicodeDecodeError` is occurring for a field (`text_log_error.line`) that is not actually needed for the `.delete()` (it's not a primary key etc), so Django shouldn't be fetching that field regardless when making the `text_log_error` `SELECT` query (Plus ideally Django would support cascade deletes, so we wouldn't need to use the current `.delete()` approach - https://code.djangoproject.com/ticket/21961) I've filed a ticket against Django: https://code.djangoproject.com/ticket/30191 ...though I doubt it's something that will get fixed either at all, or in time to help us - so I'll come up with a workaround for now. Regarding the junk `line` values themselves - they are from logs parsed when using Python 2.7 and prior to https://github.com/mozilla/treeherder/commit/4bdf9f91018b3a3306bf78db947a512f24225bab . I'm presuming with that change in place and/or once switched to Python 3, we won't have any more being inserted, but we'll at least need to handle them in cycle_data until 4 months have passed so they've all expired. Example bad `text_log_error` instance: ``` '261957356', '00:32:31 CRITICAL - 127.0.0.1 - - [20/Oct/2018 00:32:28] \"\0\0� �`���', '17652', '544935727' ```
Querying the `text_log_error` table for those ids shows there to be junk values in its `line` field. There appear to be two issues here: 1. `mysqlclient-python`'s behaviour differs depending on Python version - under Python 3 it defaults `use_unicode` to `True`, which means it attempts to decode the `line` field but fails (since it doesn't use `'replace'` or `'ignore'`). This seems like something that the Django ORM should try to protect against (eg by setting `use_unicode` to the same value on all Python versions and handling the unicode conversion itself), given it generally handles any implementation differences in layers lower than the ORM. 2. the `UnicodeDecodeError` is occurring for a field (`text_log_error.line`) that is not actually needed for the `.delete()` (it's not a primary key etc), so Django shouldn't be fetching that field regardless when making the `text_log_error` `SELECT` query (Plus ideally Django would support cascade deletes, so we wouldn't need to use the current `.delete()` approach - https://code.djangoproject.com/ticket/21961) I've filed a ticket against Django: https://code.djangoproject.com/ticket/30191 ...though I doubt it's something that will get fixed either at all, or in time to help us - so I'll come up with a workaround for now. Regarding the junk `line` values themselves - they are from logs parsed when using Python 2.7 and prior to https://github.com/mozilla/treeherder/commit/4bdf9f91018b3a3306bf78db947a512f24225bab . I'm presuming with that change in place and/or once switched to Python 3, we won't have any more being inserted, but we'll at least need to handle them in cycle_data until 4 months have passed so they've all expired. Example bad `text_log_error` instance: ``` # SELECT * FROM `text_log_error` WHERE id = 261957356; '261957356', '00:32:31 CRITICAL - 127.0.0.1 - - [20/Oct/2018 00:32:28] \"\0\0� �`���', '17652', '544935727' ```