static group asset bundle file name guid is changed by running a content update and the new catalog

[dirty-rectangle]

I’ve created a minimal project with a single static addressable group to illustrate an issue with content updates.
After running a content update my expectation is that only the generated “contentupdate_assets_all” bundle and the new catalog would need to be remotely deployed.
However, running the content update also generates a new static local bundle with a changed guid in the filename and the new catalog references this bundle, so it appears that this bundle also needs to be remotely deployed.

Steps to replicate issue…
-Create new unity project. Unity 2019.3.8f1 Windows Platform Target
-Install Addressable package 1.7.5
-Create Addressable Settings
-Turn on “Build Remote Catalog”
-Turn on “Unique Bundle IDs”
-Change “Default Local Group” to be “Cannot Change Post Release”. Using the drop down does not persist this setting so i have manually edited the corresponding ContentUpdateGroupSchema.asset file with “m_StaticContent: 1”
-Add two text file assets to the project workspace which each just contain value “1” (used for tracking the edits)
-Assign both of the text file assets to the “Default Local Group”
-Restart editor and confirm that these settings have persisted.
-Run “Build”->“New Build”->“Default Build Group”, the following files were generated
\contentupdatetest\Assets\AddressableAssetsData\Windows\addressables_content_state.bin
\contentupdatetest\Library\com.unity.addressables\StreamingAssetsCopy\aa\Windows\StandaloneWindows\defaultlocalgroup_assets_all_2f1d0f9c6f418db51f9c76a78bfa08af.bundle
\contentupdatetest\ServerData\StandaloneWindows\catalog_2020.04.15.12.34.37.json
-Run “Build”->“Clean Build”->“All”
-Exit Editor
-Edit text file “A” so that it has contents “2” in place of “1”
-Reopen project in editor and make sure the edited asset is reimported.
-Run “Tools”->“Check For Content Update Restrictions” and select \contentupdatetest\Assets\AddressableAssetsData\Windows\addressables_content_state.bin. “Apply Changes”
-Run “Build”->“Update a previous Build” and select \contentupdatetest\Assets\AddressableAssetsData\Windows\addressables_content_state.bin. The following files are generated.
\contentupdatetest\Library\com.unity.addressables\StreamingAssetsCopy\aa\Windows\StandaloneWindows\defaultlocalgroup_assets_all_e051f297f8a1d7d4e7cbe0ccf9b9f00e.bundle
\contentupdatetest\ServerData\StandaloneWindows\contentupdate_assets_all_1f786f29f9cef9f5757e0a8e45a6d1f1.bundle
\contentupdatetest\ServerData\StandaloneWindows\catalog_2020.04.15.12.38.48.json

Result:
The content update process generated a new defaultlocalgroup_assets_all asset bundle with a new guid value appended to it “defaultlocalgroup_assets_all_e051f297f8a1d7d4e7cbe0ccf9b9f00e.bundle”.
The new catalog file “catalog_2020.04.15.12.38.48.json” now references this new defaultlocalgroup_assets_all bundle and not the one from the original addressable build.
As I understand, this would mean that I would need to remotely deploy the contentupdate_assets_all bundle, the new catalog and the new defaultlocalgroup_assets_all bundle.
If only the first two were deployed it would mean that attempts to load asset “B” would result in an addressable runtime error.

The expected outcome is that the catalog generated from the content update would still reference the original defaultlocalgroup_assets_all_2f1d0f9c6f418db51f9c76a78bfa08af.bundle, and that the content update would not generate a defaultlocalgroup_assets_all with a new guid value appended. Is this a bug or is my understanding of how the content update works incorrect?

[Treyrannosaurus-Rex]

I’ll flag this for the team to check out.

[Treyrannosaurus-Rex]

I connected with the team. It was advised that you update to 1.8.3 because we did fix some stuff in the content update.

[dirty-rectangle]

I’m still seeing the same outcome having just rerun this test case using Unity 2019.3.10f1 and Addressables 1.8.3.

[Treyrannosaurus-Rex]

Gotcha - can you submit a bug report for us, that way we can look into this further: Unity QA: Building quality with passion

[dirty-rectangle]

The cause of the asset bundle filename guid renaming that i’ve described looks to be due to the addressable cache purge being run after the source addressable build and before the content update build.
So it looks like it is a dependency that this cache is maintained in the Library folder in order to prevent unchanged bundles generated from the content-update being appended with new guid values in their file names.
Having to maintain this Library cache like this places a restriction on using the content-update. Are there any work-arounds to this or do you have any planned updates to remove this dependency?

[Prodigga]

Bump, seeking an answer to dirty rectangles post. Anyone here?

[better_walk_away]

Bump this question as well. It’s still possible that Addressables would change the hash code of the groups set as “Cannot Change Post Release” in 1.10.0. This makes Asset Bundle Update System useless because we will have to update the game itself in order to update the static bundles that shipped along with the game.

[dirty-rectangle]

The (not ideal) workaround i have in place now is to configure the static groups with…
“BundleNaming” to “Filename”
“Use Asset Bunbdle CRC” unchecked

The static bundle names are then persistent with content updates.