Log complete mysqlsh error in juju log

[gboutry]

Steps to reproduce

1. have any error during a mysqlsh script

Expected behavior

Complete log error when running juju debug-log

Actual behavior

Errors are truncated at 1024 characters

['/usr/bin/mysqlsh', '--no-wizard', '--python', '--verbose=1', '-f', '/tmp/script.py', ';', 'rm', '/tmp/script.py'], stdout='', stderr="Cannot set LC_ALL to locale en_US.UTF-8: No such file or directory\nverbose: 2024-11-18T08:45:48Z: Loading startup files...\nverbose: 2024-11-18T08:45:48Z: Loading plugins...\nverbose: 2024-11-18T08:45:48Z: Connecting to MySQL at: clusteradmin@/var%2Frun%2Fmysqld%2Fmysqld.sock\nverbose: 2024-11-18T08:45:48Z: Shell.connect: tid=181: CONNECTED: /var%2Frun%2Fmysqld%2Fmysqld.sock\nverbose: 2024-11-18T08:45:48Z: Now tracking 'sql_mode' system variable.\nverbose: 2024-11-18T08:45:48Z: Connecting to MySQL at: mysql://clusteradmin@/var%2Frun%2Fmysqld%2Fmysqld.sock?connect-timeout=5000\nverbose: 2024-11-18T08:45:48Z: Dba.reboot_cluster_from_complete_outage: tid=182: CONNECTED: /var%2Frun%2Fmysqld%2Fmysqld.sock\nverbose: 2024-11-18T08:45:48Z: Connecting to MySQL at: mysql://clusteradmin@/var%2Frun%2Fmysqld%2Fmysqld.sock?connect-timeout=5000\nverbose: 2024-11-18T08:45:48Z: Dba.reboot_cluster_from_complete_outage: tid=183: CONNECTED: /var%2Frun%2Fmysqld%2Fmysqld.sock\nverbose: 2024-11-18T08:45:48Z: Group Replication 'group_name' v" [truncated]

Versions

Charm revision: 181

Log output

Juju debug log:

['/usr/bin/mysqlsh', '--no-wizard', '--python', '--verbose=1', '-f', '/tmp/script.py', ';', 'rm', '/tmp/script.py'], stdout='', stderr="Cannot set LC_ALL to locale en_US.UTF-8: No such file or directory\nverbose: 2024-11-18T08:45:48Z: Loading startup files...\nverbose: 2024-11-18T08:45:48Z: Loading plugins...\nverbose: 2024-11-18T08:45:48Z: Connecting to MySQL at: clusteradmin@/var%2Frun%2Fmysqld%2Fmysqld.sock\nverbose: 2024-11-18T08:45:48Z: Shell.connect: tid=181: CONNECTED: /var%2Frun%2Fmysqld%2Fmysqld.sock\nverbose: 2024-11-18T08:45:48Z: Now tracking 'sql_mode' system variable.\nverbose: 2024-11-18T08:45:48Z: Connecting to MySQL at: mysql://clusteradmin@/var%2Frun%2Fmysqld%2Fmysqld.sock?connect-timeout=5000\nverbose: 2024-11-18T08:45:48Z: Dba.reboot_cluster_from_complete_outage: tid=182: CONNECTED: /var%2Frun%2Fmysqld%2Fmysqld.sock\nverbose: 2024-11-18T08:45:48Z: Connecting to MySQL at: mysql://clusteradmin@/var%2Frun%2Fmysqld%2Fmysqld.sock?connect-timeout=5000\nverbose: 2024-11-18T08:45:48Z: Dba.reboot_cluster_from_complete_outage: tid=183: CONNECTED: /var%2Frun%2Fmysqld%2Fmysqld.sock\nverbose: 2024-11-18T08:45:48Z: Group Replication 'group_name' v" [truncated]

Additional context

Having the truncated before the actual error makes debugging the mysql cluster tedious, we need to ask user to re-run the command performed by the charm to have the full output.

This is not pebble truncating, but ops when using the str value of exec error.

This seems to have been introduced by https://github.com/canonical/mysql-k8s-operator/pull/473/files#diff-2ebf844b19f4f589f82ac78ad37b9bbd154c5a9e8cd0149a68c9628833cb83b4

_run_mysqlcli_script gets full error with stripped password
but _run_mysqlsh_script relies on ExecError and its str implementation which truncates at 1024.

[syncronize-issues-to-jira]

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/DPE-6038.

This message was autogenerated