Pass query change ticks to QueryParIter instead of always using change ticks from World.

[chescock]

Objective

Make Changed<T> filters work reliably with Query::par_iter_mut().

While updating my game to Bevy 0.10, I had a bug where GlobalTransform was not being updated. The problem turned out to be that I was changing Transform in a system that ran after the TransformSystem::TransformPropagate set. I would have expected that to cause a one frame delay in updates, but instead it was ignoring them completely.

When #4777 introduced QueryParIter, it consolidated code in QueryState that used world.last_change_tick() and code in Query that used self.last_change_tick. The new code always uses world.last_change_tick(). This means that any system using Query::par_iter_mut() uses the last_change_tick from the end of the previous frame, and won't see any changes made by systems that ran after it did on the previous frame.

In particular, sync_simple_transforms never sees any Transform changes made by systems that run after it.

Solution

Pass last_change_tick and change_tick from Query to QueryParIter.

[chescock]

Whoops, these types got changed by #7905 after my last fetch. Let me rebase and try again.

[joseph-gio]

This looks right, but I think a simple regression test would be helpful here.

[joseph-gio]

Thank you for adding a test!

[joseph-gio]

Is there any particular reason that you're manually initializing and calling these systems instead of just adding them to a Schedule?

[chescock]

Not really, I just copied that approach from the previous test in that file. Should I replace it with

        let mut schedule = Schedule::new();
        schedule.add_systems((propagate_system, modify_system).chain());
        schedule.run(&mut world);
        world.clear_trackers();
        schedule.run(&mut world);
        world.clear_trackers();

?

(I thought I could put World::clear_trackers in the schedule, too, but exclusive systems can't actually update last_change_tick, and without that update the test can't catch the bug.)

[joseph-gio]

Yeah, I think that looks better.

[KirmesBude]

@alice-i-cecile Not sure you are the right person, but this change has the 0.10.1 milestone label but does not appear to be included in that release.

[alice-i-cecile]

@cart was responsible for cherrypicking from the milestone this time.

[KirmesBude]

@cart Would this change warrant another minor release?

[mockersf]

I prepared the patch for the 0.10.1, and this PR depends on #7905 which is breaking so it couldn't be cherry picked. See #8029 (comment)

[joseph-gio]

I've cherry picked this PR on this branch, in case we are interested in another minor version. It seems like multiple people are affected by this problem so it might be a good idea.

[cart]

There are 56 days between today and the tentative Bevy 0.11 release date. That does seem like a reasonably long time for this to be broken. I've created a new 0.10.2 milestone and added this to it. Lets take a couple more days to consider other items for the release and then we can do the cut.