The server roll-out of the 13th September introduced a new and unexpected bug into the grid, as defined in JIRA SVC-7283:
“Attempting to issue llRemoteLoadScriptPin() on a non-full perm script to a worn/attached object fails with “Unable to add item” error message. If there was an existing script with the same name in the destination object, that script is deleted, often resulting in the items being made completely useless.
“A similar error occurs when using llGiveInventory() on a no-transfer item to a worn/attached object. In this case, the error message is “Unable to give inventory: ‘Destination did not accept'”.”
Simply put, this means that at present, attempting to update worn objects runs the risk of breaking them completely.
The JIRA is currently assigned to WorkingOnIt Linden, which means it is being investigated – indeed, Maestro Linden has commented on the JIRA, and has confirmed the bugs. He’s even offered some well-meaning advice:
“The workaround for updaters that affect attachments such as HUDs is to first drop the attachment or detach it and rez it on the ground before using the updater.”
However, this doesn’t help in all cases – particularly those using RLV items which they may not be able to remove; there are also those update systems that rely on the object being worn.
What is more worrying, however, is the seemingly casual response from Linden Lab to the issue. There has been no official indication to content creators that there is a potentially major bug impacting their items – people are being left to hear about things via word-of mouth.
Nor does the Lab – via Oskar Linden – seem all that concerned about getting a fix for the problem out sooner rather than later. Commenting on the JIRA, Oskar Linden states:
“We have traced the cause of SVC-7283 to a security fix around permissions. Due to the urgency of the security issue, we deployed the fix to all channels of the grid at once. Unfortunately, we cannot ‘roll back’ the change at this point, since doing so would compromise permissions across the grid. We are working on a fix for SVC-7283 – we hope to deploy the fix to an RC channel next week. We apologize for the inconvenience and problems with update scripts which are caused by this bug.”
So a potentially significant bug has been introduced right across the grid – and Linden Lab hope to get a fix out to 10% of the grid next week. Does this mean that if successful, the fix will be held over a further week prior to being rolled out to the remaining RC channels and the rest of the grid?
If so, it is wholly unacceptable.
The bug was apparently introduced as a result of a fix being pushed out without sufficient regression testing. Fair enough; however, if this can be done with a security fix – and given Linden Lab have successfully recreated the bugs through Maestro Linden’s tests – then frankly the normal release cycle should be foreshortened as far as possible:
- The fix should be coded
- The code should be tested for potential impact
- The code should be *immediately* release to an RC channel and baked for 24 hours on that channel
- If no significant impacts / bugs found as a result of the RC test, the code should immediately be rolled out to the rest of the grid.
And I sincerely hope that this is what Linden Lab will be aiming for. If they are – then we need a clearer statement of intent than Oskar is giving.
In the meantime, one would hope Linden Lab would at least take the issue by the horns and for once communicate the problem with their users, rather than leaving it to people to stumble upon it through either word-of-mouth or through actually encountering an update failure.
Updates
15th September
Maestro Linden reports on SVC-7283:
“We have a fix for this bug that looks promising, which is currently on Aditi (the ‘Beta grid’). The fix version right now is thermonuclear 11.09.14.240803. You can find this version on a handful of Aditi regions; I’ve been testing in the region ‘Pixelpark’, which has a large sandbox area.
“With this fixed version, llGiveInventory() and llRemoteLoadScriptPin() should be able to deliver (no-copy or no-trans) items to worn attachments as long as the attachment’s owner permissions (in terms of copy and transfer) don’t exceed the owner permissions of the item.
“The following 2 cases are still blocked, however, for security reasons:
- “Adding a no-transfer item to a worn attachment which is transferable
- “Adding a no-copy item to a worn attachment which is copyable
“These cases might be fixed in a future project, but first the server will need to support dynamic updating of worn attachments’ permissions.”
17th September
The fix developed by Maestro Linden is receiving some positive feedback from those testing it on the Beta grid; as such, it is to be rolled out to an RC channel (no details on which as yet) on Wednesday 21st September.
This probably means that the fix will not be implemented across the entire Grid for a further week.
Additionally, a further issue was uncovered relating to permissions restrictions that impact content creators (but not necessarily their customers), wherein NO TRANS items cannot be moved between root and child prims in a full permissions item. Maestro Linden has opened a JIRA related specifically to this issue, SVC-7294.
19th September: The bug fix is confirmed for a roll-out on an RC channel this Wednesday (21st Sept). Those wishing to have their regions included int eh release should submit region names to JIRA SVC-7291.
21st September: The bug fix was apparently rolled out to all RC channels today (it seems the release notes for the RC channels don’t expressly refer to the JIRA), and appears to have corrected a part of the problem for some content creators impacted by the issue, but not for others. Further updates expected.
In addition, there are still issues beyond this JIRA that need addressing – hopefully through SVC-7294, although no roll-out date is available for this yet.
27th September: SVC-7283 rolled out to main grid.
Inara Pey: Living in a Modemworld 
Inara, the most worrying aspect of this debacle was crystallised in Chorazin Allen’s post on the JIRA. Read that and weep for Second Life, because, while I don’t often agree with Chorazin (most cogently because of thge mess he made of Deitide), this time I think he might just be right.
LikeLike
Gah. I replied earlier, but looks like WP ate my own comment!
I saw Chorazin’s comment this morning after I’d posted – and he raises an interesting and valid point vis-a-vis the security “fix”. LL appear to have a partial fix out on the beta grid – but Maestro’s comments tend to underline Chorazin’s concerns.
LikeLike
I see two major roadblocks here, Inara.
1) Maestro’s fix does not address all of the routes blocked by the security “fix”, and they are clealy less than concerned about any other issues.
2) It appears from the JIRA that the proposed fix does NOT solve many of the problems caused.
The overall upshot is that Linden Lab’s efforts are so far piecemeal and inadequate. It brings back uncomfortable memories of the server 1.40.0-1.40.2 debacle of last year.
LikeLike
Yup on all fronts – although in fariness, Maestro does state the current fix on Aditi is far from perfect; however, at least someone over there recognises the problem and is trying to address the issue. 1.40.0 -1.40.2 is lieable to be on other people’s minds as well.
Sadly, it would be impossible to give an update on all changes to the JIRA (given that 19 came in just while I was sleeping!), but I’ll be continuing to try to provide broad updates as and when I can. Maestro’s was worth nothing as it at least helped people not actively watching the JIRA to read, go test, and report issues.
LikeLike