This is a bad design to begin with and most probably the root cause of your problem. I bet there is a race condition where the two tasks execute their respective communications in such an interleaved order that one notification gets lost.
A serial communication device by definition and name must have all of the communications over it strictly serialized, so the only way to make your approach work is to “atomize” the accesses, ie use a mutex to ensure that all protocol requirements execute uninterrupted by other tasks.
Since that requirement is not negotiable, you might as well use a single task to serve the device. That task typically acts as a message pump, meaning it receives asynchronous requests from other tasks in a queue and serves those in turn, being the only instance to access your serial port. All stably working drivers for serial devices and protocols I have ever seen in ~30 years function that way. All other architectures are causing little but grief and headaches.