Interesting issue with DLRs

I have been running kannel for a month or so and its been great.

I looked at the outstanding DLRs the earlier today and say a few, and  
identified some as phones that I know people are not using any more,  
hence no delivery. Thats fine, but then I noticed my number was in  
the outstanding DLRs, and after a bit of investigation I knew it was  
a message that I had received.

Looking at the debug from the smsc logs (Im using SMPP, with  
postgresql as the DLR storage BTW) I see that what has been happening  
is that the DLR is actually coming in a fraction faster that the  
submit_sm_resp with the message ID in it. (Or at least the receiver  
thread is before the transmitter thread).

This means the DLR is being ignored as its not in the table, then its  
gets created and put in the table immediately after. So its then  
outstanding, and of course the DLR callback is never run.

I wonder if a) anybody else has come across this, or b) you can think  
of any good ways to make sure the DLRs are not lost. e.g. maybe we  
store them, and then when we create them we can see the status has  
already been updated and trigger the callback?

I suspect its because I am connected directly to an operator as  
opposed to an aggregator that I am having this occasional (about 30  
messages in 600 over 7 days approx) issue.

I should also say that I set-up and did the operator integration  
testing with 1.4.0 as 1.4.1 was not out at the time (came out a  
couple of weeks after), so my live service is currently running  
1.4.0. I will upgrade, but first need to be sure of the effects of  
the upgrade, as obviously having been thought the integration testing  
I need to be careful about using a different version thats does  
something unexpected to the connection (in which case I would be in  
danger of loosing the operator connection).

So if you think this issue is only with 1.4.0 then no problem, but I  
could not see anything in any of the release notes that suggest this  
has been identified before.

Regards

Ben