Yeah so the undeterminstic behavior with that resource access has the effect that checking forSceneColor.IsValid() inside ::RenderRegion() doesn’t seem to be threadsafe, the resource or at least the return value from IsValid() can change within the execution of that ::RenderRegion() of the RenderThread. In other words, the race condition causes IsValid() to eventually be true at first, however it *may* be suddenly invalid afterwards during the Constructor of the Viewport which is used in Vanilla at the moment, assertion for IsValid() -> and crash.
Due to that racec condition-like behavior, checking IsValid() before the Constructor who asserts(isValid()) won’t resolve the potential of that crash, as IsValid() can suddenly change its return value -> implying that some other thread is manipulating that resource while the RenderThread runs on ::RenderRegion(). That is why after I switched the Construction chain to use an alternate constructor bypassing the assertion and checking validity of the Viewport Extent afterwards seems to resolve the crash. But similar to the other crash, the worrying part is why does the return value of IsValid() change during that function execution of the RenderThread, who is manipulating the RDG Resource if not the Graph? These are the 2 questions to find the root cause. The ::RenderRegion() is not within a GraphPass, accessing the underlying RHI Resource (which *can* be null here) from the RDG Resource would be invalid due to that.
We don’t have a mini dump from a pure vanilla version of this unfortunately, only from a custom build on-set so I am not sure if you would be able to read from it as you might need the custom symbols from our on-set engine build, to reading the callstack. Although I believe this particular build was mostly Vanilla to be fair, with some ICVFX patches from Epic.
And yeah these issues have been quite tricky, I had to make quite some guesses due to the undeterministic behavior and the fact that we could do only one single test-run over night if even.
Best,
Markus