This usage of the whole USD `USDStageReader` as 'cache handle' feels a
bit... uncomfortable to me. It implicitely assumes that all data in this
owned by the reader (or has a lifetime that contains the whole handle
lifetime). IMHO, if such struct is expected to have a long lifetime, it
should be documented, and probably needs better design for sub-data
handling then. Am curious to know if there is a good reason why the
handle itself is not a simple trivial class, able to re-generate an
actual complete USD reader on demand?
Or maybe we need to find a better place to store the `wmJobWorkerStatus`
data?
Anyway, for now this PR addresses the issue by ensuring that the
`worker_status` stored in the `USDImportParams` is not `nullptr` before
trying to access it for the reports.
This is more of a short-term solution though, imho there should be a way
to pass a reportlist to this codepath, and ensure the `wmJobWorkerStatus`
is always valid?
Pull Request: https://projects.blender.org/blender/blender/pulls/114337
730b5057a7