Omni.client wedges after stage load when DomeLight references unresolvable asset on Nucleus (Kit 110)

Omniverse Core Platform Kit App Template / SDK
1

Operating System: Windows
Kit Version: 110 (Kit App Template)
Kit Template: Custom (based on USD Explorer)
GPU Hardware: 30 series
GPU Driver: 595.71
Work Flow: Open a USD stage from Enterprise Nucleus (HTTPS) in a Kit 110 app; use omni.client to list directories / resolve paths after the stage has loaded.

Main Issue

Opening a specific USD stage from our Enterprise Nucleus server causes omni.client to stop responding to any further requests after the stage finishes loading. The connection remains in ConnectionStatus.CONNECTED and a browser pointed at the same Nucleus instance work normally throughout - so it is not a server-side issue. Only the Kit process’s omni.client is affected, and recovery requires a full process restart (neither omni.client.sign_out() + omni.client.reconnect() nor omni.client.set_retries(max_ms=0) recovers it).

We reduced the trigger to a 3.5 KB minimal repro: a USDA stage containing a single DomeLight with inputs:texture:file pointing at a nonexistent path, plus a trivial Mesh so the stage is not empty. Opening this file from Nucleus in a freshly-restarted Kit 110 reliably wedges omni.client.

Reproduction Steps

  1. Upload the attached repro_v7c_bare_domelight.usda to any Nucleus location (e.g. omniverse://<server>/Users/<me>/repro_v7c_bare_domelight.usda).
  2. Start Kit 110 from a clean state (full process restart).
  3. Open the file from Nucleus via the Content browser.
  4. After stage load completes, open Script Editor and run:
import omni.client
result, entries = omni.client.list("omniverse://<server>/")
print(result, len(entries) if entries else "")

The call hangs indefinitely (sync). Async calls time out. Navigator on the same machine continues to browse the server fine.

Minimal repro file

The file is 3.5 KB. The relevant content:

#usda 1.0
(
    customLayerData = { ... cameraSettings, omni_layer, renderSettings, xrSettings ... }
    defaultPrim = "World"
    metersPerUnit = 0.01
    timeCodesPerSecond = 60
    upAxis = "Y"
)

def Xform "World" {
    def Mesh "Cube" { ... trivial 8-point cube ... }
}

def Xform "Environment" {
    def DomeLight "Sky" {
        asset inputs:texture:file = @file:/C:/does-not-exist/textures/NOT_A_REAL_FILE.hdr@
        token inputs:texture:format = "latlong"
    }
}

The path in inputs:texture:file is intentionally nonexistent on the client machine (it’s a baked-in absolute file:/C:/... left over from a stage template that was authored in a different Kit install). Nothing else in the scene references any external asset.

Error log after opening the stage (the wedge begins after these errors are emitted):

[Error] [gpu.foundation.plugin] Failed to request UJITSO build result for: file:/C:/.../NOT_A_REAL_FILE.hdr:5
[Error] [rtx.scenedb] Failed to upload DomeLight texture file:/C:/.../NOT_A_REAL_FILE.hdr

Shortly after, any omni.client request to the Nucleus root (or any path) hangs.

Workaround

Before opening the stage, clear dead asset paths with a pure-Sdf pass (no stage composition needed):

from pxr import Sdf

DEAD_FRAGMENT = "ov-107.2/_build"  # or whatever identifies the broken path

layer = Sdf.Layer.FindOrOpen(src_url)

def fix_prim(spec):
    for attr in spec.attributes:
        if attr.typeName.type.typeName in ("SdfAssetPath", "asset"):
            val = attr.default
            if val is not None:
                path = val.path if hasattr(val, "path") else str(val)
                if DEAD_FRAGMENT in path:
                    attr.ClearDefaultValue()
    for child in spec.nameChildren:
        fix_prim(child)

for root in layer.rootPrims:
    fix_prim(root)
layer.Save()

After this pass, the file opens cleanly and omni.client stays responsive.

repro_v7c_bare_domelight.zip (1.2 KB)

2

Ok thanks for the post. Yes, it is not a good idea to have missing assets or incorrect paths. Best to resolve the missing assets and then it will not hang anything.