-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Add tests for asset processing to show the problem with #21269. #21433
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add tests for asset processing to show the problem with #21269. #21433
Conversation
1d1dc96
to
f97df7e
Compare
Hmmm looks like it's deadlocking for some reason? That's very strange... I can't reproduce it on my machine (and I'm also on Windows). I'll need to investigate. |
Ooof ok I understand the problem. I was able to reproduce this locally - it's very flaky. Asset processing currently requires writing the transaction log to an actual file (which we don't control). This means that if a previous test was using the transaction log (since we never kill the asset processing thread), this can leave the log in an opened state, resulting in Windows locking down the file and preventing writes from other tests. Clearly we need to be able to mock out the asset processor's transaction log. We might need to make a couple traits to mock this out. Edit: Just to clarify, this is already a problem with the existing tests. Hopefully with so few asset processing tests the likelihood is low of errors. I will try to fix this soon. |
Blocked on #21476 |
# Objective - There was a TODO to make this type actually a trait. - #21409 introduced a test flake on WIndows (since the transaction log file may not have been fully released by the time the next test ran), and made tests create the `crates/bevy_asset/imported_assets/log` file. ## Solution - Create two traits: `ProcessorTransactionLogFactory` and `ProcessorTransactionLog`. The former creates the latter. - Rewrite the test helper for asset processing to use a fake transaction log that doesn't do anything. - Note: pretty much the entire implementation was just reformatted into the trait. - Note: these transaction log methods are returning `BevyError` instead of something like `std::io::Error`. ## Testing - I ran the asset tests on repeat for a while (including with #21433 where the flake was first seen and I was able to reproduce fairly quickly). No issues! Note: we could make a release notes for the fact that users can make their own transaction logs, but this feature is primarily for unit testing. Maybe a user could make a more robust transaction log, but it's really not clear that it would be important for anyone.
f97df7e
to
807168a
Compare
Unblocked now that #21476 is merged! |
// This processor loads a gltf file, converts it to BSN and then saves out the BSN. | ||
type GltfProcessor = LoadTransformAndSave<FakeGltfLoader, GltfToBsn, FakeBsnSaver>; | ||
// This processor loads a gltfx file (including its gltf files) and converts it to BSN. | ||
type GltfxProcessor = LoadTransformAndSave<FakeGltfxLoader, GltfxToBsn, FakeBsnSaver>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I'm reading #21269 correctly, then this will have to be changed, maybe with a marker type, so that the load_source_asset
call can be told to load source assets here (or some other solution to the issue)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup that's correct. I still think it's worth it to have most of a test ready to test against. It might just be as simple as adding a bool to load_source_asset
for like processed_dependencies
or something.
807168a
to
daa638d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
awesome, thanks for the test change!
# Objective - There was a TODO to make this type actually a trait. - bevyengine#21409 introduced a test flake on WIndows (since the transaction log file may not have been fully released by the time the next test ran), and made tests create the `crates/bevy_asset/imported_assets/log` file. ## Solution - Create two traits: `ProcessorTransactionLogFactory` and `ProcessorTransactionLog`. The former creates the latter. - Rewrite the test helper for asset processing to use a fake transaction log that doesn't do anything. - Note: pretty much the entire implementation was just reformatted into the trait. - Note: these transaction log methods are returning `BevyError` instead of something like `std::io::Error`. ## Testing - I ran the asset tests on repeat for a while (including with bevyengine#21433 where the flake was first seen and I was able to reproduce fairly quickly). No issues! Note: we could make a release notes for the fact that users can make their own transaction logs, but this feature is primarily for unit testing. Maybe a user could make a more robust transaction log, but it's really not clear that it would be important for anyone.
. (bevyengine#21433) # Objective - Make the problem with bevyengine#21269 more concrete. ## Solution - Add a test to show that loaders during processing can read processed assets. - Add an ignored test to show that loaders during processing cannot currently read source assets. - This also tests that nested asset loads during processing actually works. ## Testing - Oops! All tests!
Objective
Solution
Testing