When starting pt-heartbeat on a read-only server with "--check-read-only" option, it ignores the read only status and still tries to write (and fails because the server is read only)

Using

• 5.7.35-38-log Percona Server (GPL), Release '38', Revision '3692a61'

• pt-heartbeat 3.5.1

# PTDEBUG=1 /usr/bin/pt-heartbeat --defaults-file /root/.my.pt_hearbeat.cnf --check-read-only --database percona --table heartbeat --update --utc 2>&1
(...)
# pt_heartbeat:6045 18021 Checking if server is read_only
# TableParser:3811 18021 Storage engine: InnoDB
# TableParser:3643 18021 Table cols: `ts`, `server_id`, `file`, `position`, `relay_master_log_file`, `exec_master_log_pos`
# TableParser:3811 18021 Storage engine: InnoDB
# TableParser:3826 18021 Parsed key: PRIMARY KEY (`server_id`)
# TableParser:3846 18021 PRIMARY key cols: `server_id`
# TableParser:3868 18021 This key is the clustered key
# pt_heartbeat:6126 18021 Hi-res ts: yes
# pt_heartbeat:6191 18021 Heartbeat row primary key: server_id = 4551
# pt_heartbeat:6197 18021 SELECT 1 FROM `percona`.`heartbeat` WHERE server_id='4551' LIMIT 1
# pt_heartbeat:6200 18021 No heartbeat row in table
# pt_heartbeat:6204 18021 INSERT INTO `percona`.`heartbeat` (server_id, ts) VALUES ('4551', UTC_TIMESTAMP())
DBD::mysql::db do failed: The MySQL server is running with the --super-read-only option so it cannot execute this statement [for Statement "INSERT INTO `percona`.`heartbeat` (server_id, ts) VALUES ('4551', UTC_TIMESTAMP())"] at /usr/bin/pt-heartbeat line 6205.

As seen there is a check for read only at some point but the script decides it's not read only.

Here are more details on the user's permissions and the server's settings :

mysql> show grants;
+---------------------------------------------------------------------+
| Grants for pt_heartbeat@%                                           |
+---------------------------------------------------------------------+
| GRANT SUPER, REPLICATION CLIENT ON *.* TO 'pt_heartbeat'@'%'        |
| GRANT ALL PRIVILEGES ON `percona`.`heartbeat` TO 'pt_heartbeat'@'%' |
+---------------------------------------------------------------------+
2 rows in set (0.00 sec)

mysql> show variables like '%read_only';
{+}----------------------{-}{-}{+}------+
| Variable_name         | Value |
{+}----------------------{-}{-}{+}------+
| innodb_read_only      | OFF   |
| read_only             | ON    |
| super_read_only       | ON    |
| transaction_read_only | OFF   |
| tx_read_only          | OFF   |
{+}----------------------{-}{-}{+}------+
5 rows in set (0.01 sec)

The code responsible for this is the following (unchanged since 2013 it seems) :

sub server_is_readonly {
   my ($dbh) = @_;
   my ( $is_read_only ) = $dbh->selectrow_array(q{SELECT @@global.read_only});
   if ( $is_read_only ) {
{{      my ( $privs ) = eval { $dbh->selectrow_array(q

{SHOW GRANTS}

) };}}
      if ( $privs && $privs =~ /\b(?:ALL|SUPER)\b/ ) {
         $is_read_only = undef;
{{      }}}
   }
   return $is_read_only;
{{}}}

As far as I understand, it checks the "read_only" variable and if it is set, it checks the current user's permissions and if it contains ALL or SUPER, it deems that the server is not really read only or that it does not know.

I don't see any context in the script where it would make sense. If I comment the "undef" line, it behaves as expected in my use case (not sure if it could break anything else)

(also there is no pt-heartbeat component in Jira)