PostgreSQL 12 dropped replication slot but standby is still trying to contact the primary

We have recently decommissioned a standby that was experiencing some hardware issues from our streaming replication cluster. We were able to successfully stop the PID on the primary and then drop the replication slot using **SELECT pg_drop_replication_slot('');**. Confirmed by running **SELECT * FROM pg_catalog.pg_replication_slots;** We deleted the **standby.signal** file and commented out **primary_conninfo** in the **postgresql.conf** file. I even checked the **conf.d** sub-directory to make sure there weren't any additional settings for primary_conninfo in there. We removed the entries from the HBA settings from the primary and remaining standbys, but now we are seeing HBA errors from the standby still trying to reach the primary. We would rather not remove the data directory at this point and want to troubleshoot the hardware issue on the standby so we can eventually add it back in without having to re-install Postgres to do so. Why is it still trying to contact the primary and what are we missing here I do notice that hot_standby is still set on but should that matter? Also ran **SELECT pg_wal_replay_pause();** on the standby for good measure but it didn't change anything. NOTE: I can also tell from **SELECT pg_size_pretty(sum(size)) FROM pg_ls_waldir();** that the WAL logs are not backing up.