Describe the bug
A torrent that failed in the past due to the way qBit 4.3+ handled sending back paths was tried with the latest update. It failed to import but also didn't throw an error in the UI, with the history simply showing the grab and nothing else. It looks like, for some reason, qBit or Sonarr added a forward slash at the end of the output string and this caused the problem since the host machine is running Windows. https://github.com/Radarr/Radarr/issues/1761 is another example of this kind of concatenation problem in an unrelated scenario.
Screenshots

Logs
Log.txt
System Information
Is qbit running on the same machine?
@Taloth yessir, all on the same box.
Started having the same issue.
Was working fine prior to recent update to 3.0.4.995.
Please post actual trace level logs, including that of the qbit api response that is logged at trace.
sonarr.trace.txt
Attached trace logs
Started trace logging
Searched for release
Started downloading
Download complete
Disappears from Sonarr list with no warning.
I'm not testing the same torrent, but for me I see proper backward slashes. Probably something specific to the torrent, maybe it depends on the OS the torrent was created on, but i'm not gonna dive deeper into that.
Fix will be out soon.
Not sure if this is the right place to put it
Just got 3.0.4.997 in and re-ran the same torrents that failed with 995
All good and Sonarr is processing as expected
That was quick. The linux package of 997 hasn't even finished building yet :)
Thank you for confirming.
Ack, he beat me to it! But, yeah, mine worked fine too with 3ff848b.
Thanks for the quick fix!