Skip to content
This repository has been archived by the owner on Feb 28, 2024. It is now read-only.

[BUG-6229] Wrong payment descriptions recorded when rapidly paying objects #14110

Open
sl-service-account opened this issue Jun 1, 2014 · 4 comments

Comments

@sl-service-account
Copy link

Steps to Reproduce

Create an object and add this script:

integer count = 0;

SetName()
{
    string name = (string)llGetPos() + ":" + (string)count;
    llSetObjectName( name );
}

default
{
    state_entry()
    {
        llSetPayPrice( 1, [1,PAY_HIDE,PAY_HIDE,PAY_HIDE] );
        SetName();
    }

    money( key id, integer amount )
    {
        llSay( 0, (string)id + " " + (string)amount );
        count++;
        SetName();
    }

}
  • Make the object's default action click-to-pay
  • Rapidly click and pay the object several times
  • Note that after each payment, the object is renamed with its current coordinates, followed by a serial number that increments after each payment. Example: <90.75000, 116.00000, 30.25000>:9
  • View the transaction log at: https://accounts.secondlife.com/transaction_history

Actual Behavior

  • When rapidly paying objects, the same transaction description will be used several times. For example two or three source/destination payment pairs will use Destination: (myself) Payment Region: (my region) Description: <90.75000, 116.00000, 30.25000>:9 followed by several transactions with :12. 10 and 11 were skipped. However local chat shows that the object had been correctly renamed before each payment before I clicked to issue the new payment.

Expected Behavior

  • Expected the transaction descriptions to match the issued transaction

Other information

This is worse when rapidly paying multiple owners' objects, as at a Gatcha Faire event, such as the tremendously popular Arcade. The wrong transaction description will be used, making one seller believe they are getting another seller's payments. To reproduce this case, replicate the above object on a second account and rapidly alternate between paying the two objects.

Original Jira Fields
Field Value
Issue BUG-6229
Summary Wrong payment descriptions recorded when rapidly paying objects
Type Bug
Priority Unset
Status Accepted
Resolution Accepted
Reporter Soft Linden (soft.linden)
Created at 2014-06-01T19:29:51Z
Updated at 2016-03-25T22:15:56Z
{
  'Business Unit': ['Platform'],
  'Date of First Response': '2014-06-01T18:56:05.978-0500',
  "Is there anything you'd like to add?": "This is worse when rapidly paying multiple owners' objects, as at a Gatcha Faire event, such as the tremendously popular Arcade. The wrong transaction description will be used, making one seller believe they are getting another seller's payments. To reproduce this case, replicate the above object on a second account and rapidly alternate between paying the two objects.",
  'System': 'SL Viewer',
  'Target Viewer Version': 'viewer-development',
  'What just happened?': '* When rapidly paying objects, the same transaction description will be used several times. For example two or three source/destination payment pairs will use Destination: (myself) Payment Region: (my region) Description: <90.75000, 116.00000, 30.25000>:9 followed by several transactions with :12. 10 and 11 were skipped. However local chat shows that the object had been correctly renamed before each payment before I clicked to issue the new payment.',
  'What were you doing when it happened?': 'Create an object and add this script:\r\n{code}\r\ninteger count = 0;\r\n\r\nSetName()\r\n{\r\n    string name = (string)llGetPos() + ":" + (string)count;\r\n    llSetObjectName( name );\r\n}\r\n\r\ndefault\r\n{\r\n    state_entry()\r\n    {\r\n        llSetPayPrice( 1, [1,PAY_HIDE,PAY_HIDE,PAY_HIDE] );\r\n        SetName();\r\n    }\r\n\r\n    money( key id, integer amount )\r\n    {\r\n        llSay( 0, (string)id + " " + (string)amount );\r\n        count++;\r\n        SetName();\r\n    }\r\n\r\n}\r\n{code}\r\n\r\n* Make the object\'s default action click-to-pay\r\n* Rapidly click and pay the object several times\r\n* Note that after each payment, the object is renamed with its current coordinates, followed by a serial number that increments after each payment. Example: <90.75000, 116.00000, 30.25000>:9\r\n* View the transaction log at: https://accounts.secondlife.com/transaction_history\r\n',
  'What were you expecting to happen instead?': '* Expected the transaction descriptions to match the issued transaction',
}
@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2014-06-01T23:56:06Z

Did this problem start when Secondlife.com was updated to point to the new transaction history page on May 29th?

@sl-service-account
Copy link
Author

Soft Linden commented at 2014-06-02T00:03:40Z

@whirly - Doubtful. The wrong transaction description is recorded in the db that both the new and old transaction pages source from. I strongly suspect it's an old viewer issue.

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2014-07-08T15:09:55Z

Heya Soft,

Is the fix going out to BlueSteel and LeTigre this week to address this bug?

http://community.secondlife.com/t5/Second-Life-Server/Deploys-for-the-week-of-2014-07-07/m-p/2769988

.....and improves L$ transaction logging for payments made by scripted objects.

@sl-service-account
Copy link
Author

Soft Linden commented at 2014-07-08T15:18:38Z

I don't see any indication that work has begun on this issue.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant