Happened to me on various occasions, and the (of course) unresolved ones are those involving tips. The person meant to receive the tips never receives it.

It should never be the case that money is paid through an object but the object never receives a money() event. The entire transaction should be cancelled.

The mechanism for sending events can't be 100% reliable, hence it is impossible to know accurately how many times the L$ transaction ultimately succeeds, but money() isn't triggered vs how many times the 'event' communication fails. The method for transmitting 'events' is complex and designed to be as reliable as possible in the face of grid failures - it makes several HTTP attempts initially, follows up with emails and chat to other devices the sim which can pass-on the event and also re-sends events periodically until they're explicitly acknowledged by our external server cluster.

Hence, when we see transactions (and sometimes customer reports) consistent with this happening, we don't receive any event notification from the device and sequence numbers indicate the money event never ran - I suspect this bug rather than failure of the communication mechanism.

I've also seen it happen on many occasions during testing when developing scripts for devices that handle money.

Note I have never seen a transaction that takes L$ but doesn't give it. The transactions always either succeed or have no effect. It can appear that way sometimes as the client L$ balance display may read incorrectly (e.g. show the deducted amount even upon failure), but re-logging the client will usually show the correct amount again.

The real issue is that the system seems to know the failure happened, hence those blue dialogs to the payer, but the system then does not return the money, or retry the event, it simply seems content to let it fail, and let the owner have to sort it out on their own, often with a very suspicious and upset customer who thinks they've just been ripped off.

Eltee said:

> The real issue is that the system seems to know the failure happened, hence those
> blue dialogs to the payer, but the system then does not return the money, or retry the
> event, it simply seems content to let it fail, and let the owner have to sort it out on their
> own, often with a very suspicious and upset customer who thinks they've just been
> ripped off.

I think what's happening is something like this: the sim is sending the payment request over to the central payment handling system. The payment handling system doesn't respond in a timely fashion, so the sim decides the transaction failed and tells the user and doesn't send the money() event. Then the payment system catches up with its backlog and processes the request anyway. This disconnect is seriously causing us problems.

I'd like to see LL implement a grid-wide "kill switch" (VWR-4431) as a stopgap measure. It's almost always the case that when purchases start to fail, LL knows about it and posts to the blog. Often they say something like "please refrain from purchases as necessary" and sometimes they make announcements in-world. The problem is that these announcements aren't reaching users who don't check the blog and log in after the in-world announcement. When LL knows many transactions are failing and they're working to fix the problem, they could just hit a switch to temporarily turn off transactions and save us vendors a whole heap of trouble. I know I spend a lot of time cleaning up these transactions.

Or perhaps just tying the actual money transfer to the money event more synchronously, so it wouldn't happen if the money event was not fired off or some such thing.

or even i guess making it multi part with a branch so if it failed or timed out rather than being totally linear and chuggling along and eventually completing the transfer later, it could be aborted and the money refunded, sort of like killing a job in a print queue (assuming its some kind of bottlenecking thats causing the time outs)

Of course, that's just a stopgap. The actual solution which I'm sure LL is working on right now is to prevent this from happening in the first place. Purchases of this sort should be "transactional" in nature, so that either everything happens or everything doesn't, not just some parts.

i have so many notecards from customers not recieving items i am no longer replacing them im sick and tired of it im sending them all to lindens to have them resolve it please FIX THIS

BTW, I have also seen this in both vending machines using the llMoney() function call as well as with objects simply set for sale !!

For me, this can happen dozens of times within an hour depending on how busy we are when the system gets fubar'd...