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

[BUG-9506] Repro to get clothing layers that will not take off and a persistant "httpFailure: appearance update request failed, status 400 reason Bad Request" until relog. #16999

Open
sl-service-account opened this issue Jun 22, 2015 · 2 comments

Comments

@sl-service-account
Copy link

sl-service-account commented Jun 22, 2015

Sometimes when changing outfits, adding & removing clothing layers & attachments etc you end up in a state where one or more clothing layers will not take off, even when doing a complete "replace outfit" and a relog is needed to fix it.
This can happen when just changing clothing normally, without doing anything silly.

I have a way to reproduce this state almost 100% of the time.
The repro is a bit silly & extreme, but hopefully useful.

Steps to Reproduce

  • Open Inventory -> Library -> Accessories

  • Shift select all the folders in the Accessories folder & drag the selection onto your avatar.

  • Wait 20 seconds or so for everything thats going to attach/wear to complete.

  • Right click Current Outfit folder -> Remove from current outfit, to take everything off apart from skin, shape, eyes, hairbase.

  • Observe what is left as worn and attempt to remove any clothing still showing as worn.

    Observed Behaviour

  • After performing the "Remove from current outfit", you will usually be left wearing either all the contents of the "Sock Options" folder or all the contents of the "T-Shirt options (female & male)" folder (plus a skin, shape, hairbase & eyes).

  • It only ever seems to be one of these folders that is stuck as worn, never both.

  • All attachments detach as expected.

  • Attempt to take off the still worn socks or T-Shirt layers and observe you cannot take them off, either by right clicking Current Outfit folder -> Remove from current outfit or by right clicking each worn layer individually -> Take Off.

  • Each time you attempt to remove a still worn clothing layer or add a new clothing layer, you will see the following warning in logs:

    WARNING:#Avatar RequestAgentUpdateAppearanceResponder::httpFailure: appearance update request failed, status 400 reason Bad Request
  • Observe that you do not see the stuck clothing layers visible on your avatar, but if you go into edit appearance mode (edit shape), you will then see the clothing layers visible on your avatar.
    The stuck clothing layers will remain visible after exiting edit appearance mode.

  • Replace outfit with the default avatar, Develop -> Avatar -> Character tests -> Test female (or male) & observe that the stuck clothing layers are still not unworn and they are still visible on your avatar.

  • Relog.

  • After relogging, the stuck clothing layers will be removed.

  • Log attached from BigBird-RC after a session where I went through these steps - Whirly_1.log

    Expected Behaviour

    Clothing layers should not get stuck as worn.

    Other Information

    Reproduces on:

  • BigBird-RC: Second Life 3.7.31 (302640) Jun 15 2015 11:24:01 (Second Life Release)

  • Current default release: Second Life 3.7.30 (302599) Jun 12 2015 08:53:15 (Second Life Release)

  • MAINT-RC: Second Life 3.7.31 (302685) Jun 16 2015 11:45:26 (Second Life Release)

    This does not reproduce on pre-AIS3 viewers.
    This also does not reproduce on the current codebase if you disable the AIS3 cap.
    If you reproduce the stuck clothing layers and then disable the AIS3 cap and right click Current Outfit -> Remove from current outfit, all the stuck clothing layers immediately remove, you don't even need to relog after disabling AIS3.

Attachments

Original Jira Fields
Field Value
Issue BUG-9506
Summary Repro to get clothing layers that will not take off and a persistant "httpFailure: appearance update request failed, status 400 reason Bad Request" until relog.
Type Bug
Priority Unset
Status Accepted
Resolution Accepted
Reporter Whirly Fizzle (whirly.fizzle)
Created at 2015-06-22T10:20:18Z
Updated at 2015-07-19T02:43:44Z
{
  'Business Unit': ['Platform'],
  'Date of First Response': '2015-06-27T11:03:44.676-0500',
  'Severity': 'Unset',
  'System': 'SL Viewer',
  'Target Viewer Version': 'viewer-development',
  'What just happened?': '...',
  'What were you doing when it happened?': 'Filling in...',
  'What were you expecting to happen instead?': '.',
}
@sl-service-account
Copy link
Author

Kitty Barnett commented at 2015-06-27T16:03:45Z, updated at 2015-06-27T16:04:56Z

I addressed this last night and guess I should leave a comment to help shortcut some findings:

  • AIS updates are arriving or processed out of order; if you look at the descendent accounting and look at the remote COF version you'll notice that the viewer can handle a message for 13018 before it handles a message for 13017

  • the RemoveItemCommand AIS class should implement httpFailure and handle the 410 status code ; the reason items stay stuck on AIS but not pre-AIS is that the legacy message will always local delete the inventory item. In this case the items exist only on the viewer and not the server so when the AIS remove command is issued the server will respond with 410 Gone and the item is stuck. Handling 410 and deleting the local item (and aborting the retry since it'll never succeed) when it doesn't exist on the server will keep COF clean

    The second part about appearance requests failing is due to COF version accounting not being identical with AIS and using "legacy" messages; with AIS the viewer's COF version will start to deviate from the server's COF version (especially with the remove item message and "immediate deletion") and the update request will fail from that point on (seems to return 4XX in the case of the viewer COF getting ahead of the server)

    I used the IncrementCOFVersion cap to bump the server version and then slam the new COF version onto the local COF category to bring them back in sync. Appearance requests start to work properly again from that point on without the user needing to relog. It's not a proper fix for version accounting but it does work as a failsafe.

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2015-07-19T02:43:44Z

I can confirm testing a build with Kitty's fixes does indeed fix this problem.

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