Micropython MQTT freezes when Publishing to a Subscribe topic after several days

[Fre19]

ISSUE
Though it is probably a bad practice to 'publish' to a 'subscribe' topic in the same micropython script, it is certainly important to know the consequenses since it may save you days if not weeks trying to find out what is wrong.

Environment
MicroPython v1.22.2 on 2024-02-22; Generic ESP32 dev module with ESP32 WROOM
IDE Thonny 4.0.2
My_MQTT: mosquitto mqtt on a NAS in my LAN
MQTT_explorer: PC application to monitor topics from a broker, or to send 'something' to a 'subscribe' topic

script excerpt:
mqtt lib from micropython
from umqtt.robust import MQTTClient
mqtt setup

client = MQTTClient(client_id=xxxx, user=xxxx, password=xxxx, server=xxxx, port=xxxx)
client.set_callback(subscribe_cb)
client.connect()
client.publish(topic_bPUB, code)
client.subscribe(topic_bSUB)

bPUB = 'root_topic_pub/'
bSUB = 'root_topic_sub/'

try:
client.publish((bSUB + publish).encode('ascii'), 'ping')
except:
print('err')

application:
every 10", data from an electricity meter is published on My_MQTT
The idea to publish a 'ping' to the subscribe topic was to read it back via the client.check_msg() function in a while loop. This msg from the client.check_msg() would serve as a positive confirmation that the MQTT broker would be up and running if a 'ping' would be received.
Next to this, the subscribe topic would also be used to read parameters, manually sent via MQTT_explorer.

effect
All seemed to work well, but after a few days, publishing of ALL topics froze on the MQTT_explorer screen, yet the $SYS on the broker indicated that 'some' communication the broker was ongoing every 10".

IDE repl
On the Thonny console, all output was frozen as well (print messages from my script), micropython was frozen but not crashed it seemed:
At each ctrl_c, a print message from the script was released, untill
after several ctrl_c commands micropython was ended with >>> characters

publishing 'something' to a previously defined 'subscribe' topic seemed to be the culprit

Expected behavior
Though this was a bad practice, some kind of ERROR message from micropython whould have been appreciated.