From your description and the fact that you are on fedora I'm guessing that this happened because fedora uses experimental systemd service startup to manage the session. The caveat there is that the drkonqi process is part of the unit that crashed, which then means that if systemd decides to restart the unit (which it will when crashed) it will forcefully terminate drkonqi because it cleans up the previous processes spawned by the unit.

For 5.22 there's nothing we can do about that. In 5.23 there's a new coredumpd based post-mortem system where drkonqi doesn't actually directly relate to the process that crashed, but the process terminates, its memory gets recorded by systemd's coredumpd and then we start drkonqi from there to debug the dumped process rather than the live process (that eventually gets killed by systemd).

The thing is, as far as I am aware fedora is using ABRT instead of coredumpd to handle these crashes, so practically speaking fedora probably shouldn't be shipping/enabling drkonqi at all but use ABRT. Certainly not in 5.22 because of the described problem. The latest kcrash sports an environment option KCRASH_DUMP_ONLY=1 for that. When set drkonqi is not started by the crashing application but the app will dump its core, invoking the global core handler (supposedly ABRT) and everything else happens there. You may want to bring this to fedora's attention.