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.
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
Auto-reply emails from Gmail (and similar services) are sent to @amazonses.com instead of @im.agni.lindenlab.com, breaking in-world delivery
When a user sets up an automatic email reply (e.g., vacation responder or canned response in Gmail) for incoming Second Life emails, the auto-reply is incorrectly addressed to an Amazon SES bounce/proxy address (something like xxxxxxx@amazonses.com ) instead of the original Second Life IM gateway address ( username@im.agni.lindenlab.com ). As a result, the auto-reply never reaches the sender in-world, and the original sender receives no indication that their IM triggered an out-of-office or automated response. Steps to reproduce (Gmail example): In Gmail, enable “Canned Responses” / Templates (Labs/Settings → Advanced). Create a new template with your desired auto-reply text. Create a filter that matches incoming emails from @im.agni.lindenlab.com (or specifically the Second Life IM address). In the filter actions, choose “Send template” and select the template created in step 2. From another Second Life account, send an in-world IM to the avatar whose email has the auto-reply configured. The IM arrives as an email → Gmail sends the canned response automatically. Observe the “To:” address of the sent auto-reply: it is an @amazonses.com address, not @im.agni.lindenlab.com . Expected behavior: The Reply-To or the effective destination should preserve the original @im.agni.lindenlab.com address (or provide a correct Reply-To header) so that auto-replies from users’ mail clients are delivered back into Second Life as IMs. Impact: Users who rely on out-of-office replies, support bots, or automated responses cannot inform senders that they are away or that messages are being handled automatically. This breaks a long-standing and heavily used feature of the email-to-IM system. Thank you for looking into this!
10
·
tracked
Flying vehicle across border into damage-enabled land causes injury (often immediate death)
Locations where this happened earlier this evening: Solang / Les Cigalons (near 155, 11) Rua / Old Cave of Rua (near 70, 12) Sequence: You're flying across a sim border. The land you're about to enter in the target sim has damage enabled. "Injured" noise plays. You die and are teleported home. This has happened to me several times over the last week. This is likely related to a highly repeatable bug in which a vehicle gets nudged by a few degrees (sometimes moreso) when going over a border. If you want to see that bug, try landing at Hollywood Airport in Santa Catalina, where the runways are very close to the edge. You'll often find the nose of your aircraft pointing in a slightly different direction after you've crossed the border. There seems to be some kind of spurious collision event that takes place, even if it's an airplane and not in contact with anything at all. The phenomenon doesn't always have the same magnitude, but the hysteresis of "nudging" seems to scale inversely with aircraft mass. I have a very small aircraft (motorcycle-sized) that can be thrown off by multiple tens of degrees. Larger aircraft seem less susceptible: something the size of a Cessna 172 might get "tilted or panned" by 15 degrees or less. Corroborating evidence: The "nudging" effect is readily apparent at low speeds, when the aircraft's kinetic energy isn't much higher than that of an avatar. Go over a border at 30 meters/sec, when the aircraft's kinetic energy is many times higher than that of an avatar, and the effect is less apparent. My guess would be that this is a race condition that occurs while linking the avatar to the seat on the airplane as the handoff completes: they collide with each other during the split second that elapses between bringing the avatar into the sim, and linking it to the seat. Now, does the avatar have to be non-phantom while this is occurring? Probably not. Avatar collision hull is useful on vehicles, but it's not so critical that you couldn't do without it for a moment on region handoff. As I recall, over damage land, collisions can injure avatars, and vehicles forward damage to avatars as well. So, if the avatar is colliding vigorously with the airplane for a split second due to this phenomenon, the avatar would take damage.
18
·
tracked
Load More