[EMSUSD-2306] Session-layer specs moved to root layer after reparenting prims in v0.30+

[jufrantz]

Describe the bug

We rely on specific metadata and attributes to remain in the scene’s session layer for pipeline reasons, to prevent unwanted propagation to other scenes/departments. Starting with maya-usd v0.30, we notice these specs are unexpectedly moved to identified layers, after reparenting prims in maya, breaking our workflow.

---

Steps to reproduce

1. Open the provided maya scene (see attached maya-usd_parenting_vs_session_overs.zip).

   • The proxyShape uses maya-usd_parenting_vs_session_overs.usd as root layer:

     #usda 1.0
     
     def Xform "root1"
     {
         def Xform "group1"
         {
             def Sphere "Sphere1"
             {
             }
         }
     }
     def Xform "root2"
     {
     }
     

   • The session layer saved with the maya scene contains a few overs, on Autodesk:Use Text Color customData and visibility, they are intentionally edit-routed to the session:

     #usda 1.0
     
     over "root1"
     {
         over "group1" (
             customData = {
                 dictionary Autodesk = {
                     double3 "Text Color" = (0, 0, 0)
                     bool "Use Text Color" = 1
                 }
             }
         )
         {
             over "Sphere1"
             {
                 token visibility = "invisible"
             }
         }
     }
     

2. Reparent group1 under root2, by using the hotkey p or cmds.parent("|stage1|stageShape1,/root1/group1", "|stage1|stageShape1,/root2").

3. Print out both the root and session layers. Notice that the metadata and attribute specs - previously in the session - are now moved to the root layer.

   Session layer after parenting:

   // USD Layer identifier: anon:0x1a785fa0:maya-usd_parenting_vs_session_overs-session.usda
   // Real Path: 
   // #usda 1.0
   // 
   // over "root1"
   // {
   // }
   

   Root layer after parenting:

   // USD Layer identifier: maya-usd_parenting_vs_session_overs.usd
   // #usda 1.0
   // 
   // def Xform "root1"
   // {
   // }
   // 
   // def Xform "root2"
   // {
   //     def Xform "group1" (
   //         customData = {
   //             dictionary Autodesk = {
   //                 double3 "Text Color" = (0, 0, 0)
   //                 bool "Use Text Color" = 1
   //             }
   //         }
   //     )
   //     {
   //         float3 xformOp:rotateXYZ = (0, -0, 0)
   //         float3 xformOp:scale = (1, 1, 1)
   //         double3 xformOp:translate = (0, 0, 0)
   //         uniform token[] xformOpOrder = ["xformOp:translate", "xformOp:rotateXYZ", "xformOp:scale"]
   // 
   //         def Sphere "Sphere1"
   //         {
   //             token visibility = "invisible"
   //         }
   //     }
   // }
   // 
   

Expected behavior

Prior to v0.30, reparenting would correctly move the specs in both the root and session layers, preserving the session specs in-session. For example, with v0.29 the session layer after parenting becomes:

  over "root1"
  {
  }

  over "root2"
  {
      over "group1" (
          customData = {
              dictionary Autodesk = {
                  double3 "Text Color" = (0, 0, 0)
                  bool "Use Text Color" = 1
              }
          }
      )
      {
          token visibility = "invisible"
      }
  }

---

Specs

• OS: Rocky Linux 8.10
• Compiler: gcc 9.3.1
• Maya version: 2025.3
• Maya USD version: 0.30.0 (also reproducible in 0.31 and dev)
• Pixar USD version: 23.11

---

Additional context

Reverting #3874 in release/v0.30.0 restores the previous (and desired) behavior, suggesting that the issue is related to those changes.

[wallworm]

Thank you for reporting. We will look into this.

[wallworm]

Just a head's up. We have scheduled this defect for a fix so you should see some movement on it before too long.

[jufrantz]

Great, thanks for the heads-up @wallworm. I’ll keep an eye on it.

[jufrantz]

@wallworm, @pierrebai-adsk, We tested a build that includes #4292 and #4278, and everything looks good on our end. Many thanks for addressing this.

[santosg87]

closing this issue bassed on the last comment :)