Server Bugs

• Use concise, precise descriptions
• Do not include sensitive information.
• Create a support ticket at https://support.secondlife.com for individual account issues or sensitive information.
When an object is paid the object name being recorded should be controlled by the Server and not the Viewer
Edit: Edited this after the SUG on 5/13 to add some notes, and fix up a bit. I originally wrote this in a rush since it was brought up in the Skill Gaming User Group meeting prior to the SUG meeting. Currently, when someone pays an object in Second Life, the name of the object that is being paid is sent by the Viewer to the server. This allows incorrect entries being entered into the transaction logs of residents, most especially causing issues in the Second Life Skill Gaming space where we are bound by policy to name objects certain ways (such as object names starting with [slgaming]). In the transaction log of some people, the object name is either recorded as a blank, or the object DESCRIPTION is used as the NAME of the object being paid. This is because of bad implementation of whatever viewer they are using. Both official SL viewer, and firestorm put the object name in this server call. Some bot viewers, or other viewers do not. While this could be seen as a viewer issue, this is ripe for exploitation as well as just bad design. The server itself should know that an agent is paying an object, and said object should record itself properly in the transaction description which will eventually show on the website. The server works properly when an object pays an agent, but not the other way around. The viewer leaving a comment should be preserved for resident to resident transactions, but the server should record the object name as the comment when an agent pays an object. The viewer should not be able to force a comment of its choosing with an agent to object payment. The source code in question is here: https://github.com/secondlife/viewer/blob/008c8f7c86e4ee8c672735a45928bf3019f5272a/indra/newview/llviewermessage.cpp#L374 I am classifying this as a bug, because multiple times throughout the years, Skill Gaming operators have been alerted by Linden Lab that our "transaction descriptions" are out of compliance, but this isn't anything we can control and isn't our fault. We've tried to get this addressed to no avail. I made a proposal on a llTransferLindenDollarsComment type command ( https://github.com/secondlife/jira-archive/issues/8316 ) but was never implemented but even if it was, it would only apply to object to agent payments, which are already recorded properly by the server. The issue is in play only on agent to object payments.
2
·

tracked

Non-graceful disconnects can result in stuck or broken caps
Steps to reproduce Go to any region. Crash the viewer in a way that it doesn't properly send the logout message. Attempt to log back in. May take a few times, but once you get it, it's hella annoying. The issue Once the bug is triggered, the agent in the region will eventually disappear, especially so if the agent tries logging back in. Once the agent does log in, the region will refuse to grant capabilities to the agent (Login server passes the simulator address and seed caps, but the seed cap will return 404). This will last for more than 15 minutes where the agent is unable to log into that region. Work arounds To just log in: Log into any other region (Home, etc). To get back into the region: Log into any other region. Enter the region that you crashed in (Sometimes this may have a stalled TP which results in a disconnect). (Observation) Observe that no mesh loads, as the capabilities are returning 404 for the region. Log out (Gracefully!). Log back in (Capabilities will now be granted in that region because of the graceful log out). Live reproduction On the region Fractal: Crashed at about 2024-05-17T23:54:08.666700Z Logged back in (to fractal) at about 2024-05-17T23:55:00 (Estimate because cant query the timestamp cube) (Capabilities borked) Logged back in (to home) at about 2024-05-17T23:56:15 (Estimate) Teleported into fractal at about at about 2024-05-17T23:56:45 (Estimate) (Capabilities borked) Logged out at about 2024-05-17T23:57:45 Logged back in at about 2024-05-17T23:58:15 If you are unable to reproduce this, I would gladly reproduce this issue on a specific region and provide timestamps. Error log (From viewer) 2024-05-17T23:55:04Z INFO #AppInit#Capabilities# newview/llviewerregion.cpp(317) requestBaseCapabilitiesCoro : Requesting seed from https://simhost-06639c25759dd162e.agni.secondlife.io:12043/cap/1e31ed80-9ac3-336c-ff8b-a26c82f6dc9e region name region id 00000000-0000-0000-0000-000000000000 handle 649811372272128 (attempt #7) 2024-05-17T23:55:04Z WARNING #AppInit# newview/llstartup.cpp(1511) idle_startup : Failed to get capabilities. Backing up to login screen! 2024-05-17T23:55:04Z WARNING # newview/lltoastalertpanel.cpp(195) LLToastAlertPanel::LLToastAlertPanel : Alert: We're having trouble connecting. There may be a problem with your Internet connection or the Grid. You can either check your Internet connection and try again in a few minutes, click Help to view the Support Portal, or click Teleport to attempt to teleport home. 2024-05-17T23:55:04Z INFO # newview/llworld.cpp(327) removeRegion : Removing region 151296:256512 2024-05-17T23:55:04Z INFO #AppInit# newview/llstartup.cpp(3131) setStartupState : Startup state changing from STATE_SEED_GRANTED_WAIT to STATE_BROWSER_INIT 2024-05-17T23:55:04Z WARNING #CoreHttp# llcorehttp/_httppolicy.cpp(413) stageAfterCompletion : HTTP request 0x589aebdf6180 failed after 0 retries. Reason: Not Found (Http_404) 2024-05-17T23:55:04Z WARNING #CoreHTTP# llmessage/llcorehttputil.cpp(275) onCompleted : Possible failure [Http_404] cannot POST url 'https://simhost-06639c25759dd162e.agni.secondlife.io:12043/cap/1e31ed80-9ac3-336c-ff8b-a26c82f6dc9e' because Not Found 2024-05-17T23:55:04Z INFO # llcommon/llsdserialize_xml.cpp(424) parse : LLSDXMLParser::Impl::parse: XML_STATUS_ERROR parsing:cap not found: '1e31ed80-9ac3-336c-ff8b-a26c82f6dc9e' 2024-05-17T23:55:04Z INFO #AppInit#Capabilities# newview/llviewerregion.cpp(330) requestBaseCapabilitiesCoro : Aborting capabilities request, reason: returned to login screen
1
·

tracked

Load More