Saving New Outfit Causes other saved Outfit items to be lost and Loose pants too | FirestormOS 6.6.17

[life777eternal]

Greetings, last month I had noticed something unusual when saving a new outfit on the new version of FirestormOS 6.6.17. The New outfit doesn't get saved, and the items/links in the previously saved outfits are lost. Plus for some weird reason the pants from another outfit got detached as well.

After a relog and tried to save the outfit again, the other items in my previously saved outfits are lost.

Thank you.

This does seem to be only happening on Halcyon. It's not happening on Osgrid. https://jira.firestormviewer.org/browse/FIRE-33598

[appurist]

I have been looking at this issue as well, after a report from Ashember Love (on the Rookery Pro Halcyon grid).

It seems that Firestorm has made significant changes to inventory management, after version 6.6.15, such that it leaves the user account unable to login. (Halcyon can no longer find the inventory skeleton for the user.)

Note that Firestorm 6.6.15 does not trigger this issue, so it is related to one of the changes in Firestorm 6.6.16 or 6.6.17.

Still, the problem is somewhat permanent for a user account in that there isn't a user-manageable way to fix the missing inventory skeleton once a login is attempted with a newer Firestorm.

There are a couple of separate things here, but I have always been frustrated with the inability for the Halcyon server to just repair a user with a missing skeleton, but creating a new empty one. This would at least allow the login to continue, where the user can manually adjust their appearance with the standard viewer tools.

But a second concern here is that in these cases, the user does have an inventory skeleton, but attempting to login with a newer Firestorm causes that to become lost, or overwritten. I suspect maybe overwritten with a NULL UUID for the inventory root, or something like that.

If you have an account that is unaffected, you can avoid the issue by avoiding the Firestorm upgrade; continue to run 6.6.15 or earlier. I'm investigating what we can do to fix the damaged inventory root.

[appurist]

I attempted to log in with FS 6.6.17 and received the error: [LOGIN END]: Error retrieving inventory skeleton of agent... which means that somehow the user's inventory skeleton was no longer available. I patched in a m_userManager.CreateInventorySkel(userProfile); in the handling for that error case (after making CreateInventorySkel public) as a test and I had no trouble logging in with 6.6.17, repeatedly. However, of course I had no appearance and a basic default inventory. I've been creating several new users so it is possible that this only affects new users who haven't logged in yet, but I don't think so. However, once I do create the inventory skeleton as above, FS 6.6.17 no longer has any trouble logging in. That said, a second problem/symptom is visible, in that it does not seem possible to create an inventory folder (and the variations on that) with FS 6.6.17.

I cannot commit/PR the CreateInventorySkel call because that is just patching the symptom. It is still unclear why FS 6.6.17 produces the inability to load the inventory skeleton in the first place, as that is a server-side operation. I have very limited time to investigate this which is why I haven't had much chance to dig deeper.

[appurist]

It seems there's a fundamental comms issue with the CAPS, perhaps due to "new" CAPS expected.

In my local tests,

2024-02-09T19:37:59Z WARNING #CoreHttp# llcorehttp/_httppolicy.cpp(434) LLCore::HttpPolicy::stageAfterCompletion : HTTP request 000001E75697E2F0 failed after 0 retries.  Reason:  Bad Gateway (Http_502)
2024-02-09T19:37:59Z WARNING #CoreHTTP# llmessage/llcorehttputil.cpp(282) LLCoreHttpUtil::HttpCoroHandler::onCompleted : Possible failure [Http_502] cannot POST url 'http://localhost:9501/CAPS/EQG/cfc2a516-4c17-4485-80f6-f55111407ca8/' because Bad Gateway

I looked back through the viewer log to see where the event queue was initialized and it seems there was a problem there:

2024-02-09T19:37:39Z INFO #LLEventPollImpl# newview/lleventpoll.cpp(142) LLEventPolling::Details::LLEventPollImpl::start : LLEventPollImpl::eventPollCoro with  url 'http://localhost:9501/CAPS/EQG/cfc2a516-4c17-4485-80f6-f55111407ca8/
2024-02-09T19:37:39Z WARNING # newview/llviewerregion.cpp(3491) LLViewerRegion::getCapability : getCapability called before caps received for SimulatorFeatures
2024-02-09T19:37:39Z INFO #AppInit# newview/llstartup.cpp(3886) LLStartUp::setStartupState : Startup state changing from STATE_MULTIMEDIA_INIT to STATE_FONT_INIT

in particular, that "LLViewerRegion::getCapability : getCapability called before caps received for SimulatorFeatures" message.

This could be related to a viewer change in the startup process that results in the EQG cap being used prematurely (before the region has allocated it). I'm not sure what is going on here. I don't know the CAPS system much at all and it's been years for what I do know. Just that it looks like there are some errors here that may be related.

FYI, a "SHOW CAPS" on the region console while logged in with FS 6.6.17 does not include any EQG caps, which probably explains that 502 gateway error (although that is a bit of a strange code for that).

[appurist]

It's not the CAPS error, I get the same error with 6.6.14 with a viewer that works just fine. No problems logging in or creating folders, outfits, etc with 6.6.14.

My investigation ends here; I think this will require a viewer developer to diagnose which change in Firestorm isn't compatible with Halcyon, although once identified it might require a Halcyon change to fix it.

[life777eternal]

Thank you @appurist for your efforts, I made a comment on the Firestorm issue post [FIRE-33598] and asked Beq to have a look at your comment.

[emperorstarfinder]

Some of this would appear to be related to a change LL made with viewers that the TPVs also abide by now relating to duplicate system folders. Viewers will now block loading any inventory if duplicated system folders are detected. The reason is because maniuplating inventory in the state of duplicate folders can cause corruption. See: https://wiki.firestormviewer.org/fs_missing_inventory for more information on Firestorm's handling of this.

I suspect another part of this issue is being caused by the more recent changes relating to inventory and PBR implementation. Some of these changes have in fact introduced new CAPs which Halcyon likely does not have including the proper support pieces in the Halcyon code base.

[beqjanus]

My guess is that Halcyon is missing changes that were applied to OpenSim core in April 2022.
Specifically
capabilityNames.append("FetchLib2"); capabilityNames.append("FetchLibDescendents2"); capabilityNames.append("FetchInventory2"); capabilityNames.append("FetchInventoryDescendents2");

`commit 43a184477aaf0055542185bf787685f22cfd6b74
Author: UbitUmarov [email protected]
Date: Sat Apr 23 14:53:03 2022 +0100

enable the new caps by default. Should have no side effects

commit 71f856bfa86b58dd3e1554a846e7a459caeabc27
Author: UbitUmarov [email protected]
Date: Fri Apr 22 16:16:04 2022 +0100

put back updated FetchLib2 cap. Still no viewer uses it, disabled`

[beqjanus]

I don't think that those were new caps even then, I think they were introduced many years ago but were dormant, I am not 100% certain on that. However, that would be the first place I would suggest that you look.

There have been a number of new caps over recent years. The PBR viewer, of course, has specific ones, these build upon the generic update caps that were part of the EEP development phase. In addition, there have been changes around estate management and other admin functions that may also be missing if you are two years or more adrift from core.