#ExclusiveEntityTransaction breaks hierarchy window

1 messages · Page 1 of 1 (latest)

alpine ridge
#

When running a job that takes multiple frames using ExclusiveEntityTransaction the hierarchy window doesn't wait for ExclusiveEntityTransactionDependency to complete, therefore it fails to open with the following stacktrace:

📎 Stacktrace.txt
uneven fox
#

@rich geyser ^

rich geyser
#

That's good to know. Thanks for the ping @uneven fox. I'll take a look ASAP.

rich geyser
#

@alpine ridge I'm filing a bug on your behalf, can you give me some basic information, like Entities package version, Unity editor version, and the most basic steps I can take to repro, as close as your setup as possible?

alpine ridge
rich geyser
#

Great, thank you!

alpine ridge
#

@rich geyser Is there a place to track this issue? Or maybe it's already been fixed internally?

rich geyser
#

It's being tracked internally and, while there might be a way of making it available to the public, I have no idea how. It's not been fixed yet: lots of fires to put out at the moment, but it is still on my radar.

alpine ridge
#

@uneven fox @rich geyser Has this been fixed in 1.0.14 by any chance?

rich geyser
#

There is a fix in review as we speak. It's not a trivial fix however and some trade-offs are necessary. The current implementation of the fix forces the long-running jobs to complete to allow the tools to run. It's the only way to guarantee that the tools are not frozen forever. The other approach is to block tools while long running jobs are running. We're weighing both options, leaning on the former at the moment.

alpine ridge
#

I think IN-39544 has been marked as in progress for a while so it may have been fixed in 1.0.14

rich geyser
#

The other bugs are not in my pile, even though they are somewhat related. I'll let @uneven fox comment on those.

uneven fox
#

45140 i asked about, 40943 is in progress

#

39544 is also in progress

#

i bet probably none of them are fixed in .14

alpine ridge
tulip oxide
#

This won't cause all long running jobs to complete right? Just ones tracked by EM (or using exclusive?)

uneven fox
#

i haven't seen the fix but i would think it would be possible to wait only on the ones to do with the world (and therefore the EET) in question

alpine ridge
uneven fox
#

so that's actually less crazy than it sounds, potentially, because when an EET is active and in a job, that job is the only person allowed to talk to the world in question period

#

so waiting on the EET job should be more or less identical to waiting on all jobs for the world, i would think. but eet's are tricky, sometimes i get confused

#

(all the "all jobs" functions should really be "for this world" because i don't think anything can complete all jobs for all worlds without explicitly iterating through world.all)

tulip oxide
uneven fox
#

yeah we don't even expose a way to do that from c++

tulip oxide
#

if i have a long running job outside the ownership of the EM it doesn't really need completing, hence was just checking

alpine ridge
uneven fox
#

lol 💀

#

yo dawg i herd u liek sync points

alpine ridge
#

I'm very fun at parties lol

alpine ridge
tulip oxide
#

please don't even joke mopSweat, i've just spent like 2 months ensuring my jobs can run into the next frame - so much unused space in presentation/initialization!

uneven fox
#

in this particular case it is kind of asking to sync on this one thing though

#

yeah presentation and initialization are bummers

alpine ridge
#

By blocking the tools I mean

rich geyser
#

So, the solution at the moment is to end (ie complete) the active EET. Which should not affect any non tracked jobs. The only reason we're worried about waiting for an opening is that it's easy to imagine a situation where you lock yourself out of any tooling forever. We can message you about it, I guess, but that's equivalent to closing the tool. In which case, you can also close the tool if it interferes with your specific long-running job in an unacceptable manner. That's the current thinking anyway. We'll try a few more scenarios.

alpine ridge
#

@uneven fox did you get an update on 45140 ?

uneven fox
#

nope. logging people are probably some combination of laid off and on vacation

uneven fox
#

now they say pr ready by end of week hopefully, and then it needs backporting, and then a patch release. so a while

#

(netcode people stepping in to help with logging, thankfully)

rich geyser
#

So, the editor fix has landed in master and is waiting approval on backports. We went the route of completing EETs at the tooling level.

alpine ridge
alpine ridge
#

@rich geyser @uneven fox Did the fix make it into 1.0.16?

alpine ridge
#

@uneven fox 👀

uneven fox
#

(got this confused with another bug) i'll try bugging people again today

alpine ridge
#

I also reported a new logging regression in general @uneven fox

uneven fox
#

yeah it's all messed up

alpine ridge
uneven fox
#

yeah, and it's i think picked up by somebody technically, but i'm sure they have less time for it than the actual logging team did

uneven fox
#

attempting to read jira tea leaves, it seems like it was only fixed in 1.1 experimental

alpine ridge
alpine ridge
uneven fox
#

yeah might as well. things kind of chaotic internally at the moment due to some code churn

alpine ridge
#

@uneven fox Reported as IN-55834 UnityChanSalute

alpine ridge
#

@uneven fox Also for some reason I don't have access to the report, maybe I got banned after reporting too many bugs 😆

image.png
#

But as long as you guys can see it I guess it's fine

uneven fox
#

that's probably just a jira bug

#

which happens a lot

#

we always get that for like 10 minutes after a bug is reported, for example

alpine ridge
#

Well can you confirm that you do see the report?

uneven fox
#

that's just one known issue

#

looking

#

yep visible