Skip to content
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

Fix: product ending with _1 confuses expected files validator #125

Conversation

kalisp
Copy link
Member

@kalisp kalisp commented Feb 7, 2025

Changelog Description

ValidateExpectedFiles resolved burnin .mov file containing _1.mov as sequnce and exploded it into multple expected files.
Now logic does this only for image sequences, it doesn't make sense to recalculate expected files for movie like representations.

Testing notes:

  1. create product like renderSmthMain_1 in Nuke
  2. publish to DL, publish job shouldnt fail

renderMain_1.mov caused issues as was recalculated by frames provided into multiple files.
… bugfix/AY-7453_Deadline-product-ending-with-_1-confuses-expected-files-validator
@kalisp kalisp added type: bug Something isn't working sponsored This is directly sponsored by a client or community member labels Feb 7, 2025
@kalisp kalisp self-assigned this Feb 7, 2025

# Update the expected files
expected_files = job_expected_files
is_video = f'.{repre["ext"]}' in VIDEO_EXTENSIONS
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would rather check if is in IMAGE_EXTENSIONS...

Copy link

@MilaKudr MilaKudr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Screenshot 2025-02-11 100223


# Update the expected files
expected_files = job_expected_files
is_image = f'.{repre["ext"]}' in IMAGE_EXTENSIONS
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I know representation["ext"] is not 100% required to be set, it used to be totally valid to have representation data as e.g. {"name": "exr"} without specifying ext.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it? I though it is requirements...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, made logic bit safer.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually - I did a search over the codebase and didn't quickly find any place where we're still generating it without "ext". But I'm quite sure it used to be optional - but it doesnt seem to be now anymore...

So ignore me, definitely doesn't seem optional anymore. 👍

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry about that @kalisp - I'd say, feel free to revert... and then if we face errors somehow we should be fixing the ext requirement elsewhere most likely.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was optional, when we started to use it, but that's a long time ago.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But there is some issue for representation as a folder, so what will be in those?

Copy link
Member

@iLLiCiTiT iLLiCiTiT Feb 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have answers to everything, my guess is that the "ext" would be filled to None, which should not break logic here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But there is some issue for representation as a folder, so what will be in those?

Those are still required to have ext plus that is currently NOT implemented so can be disregarded for this PR I'd say.

… bugfix/AY-7453_Deadline-product-ending-with-_1-confuses-expected-files-validator
…ending-with-_1-confuses-expected-files-validator' into bugfix/AY-7453_Deadline-product-ending-with-_1-confuses-expected-files-validator
It was highlighed that `repre["ext"]` might not be required. This should be safer.
@kalisp kalisp requested a review from BigRoy February 11, 2025 11:34
@kalisp
Copy link
Member Author

kalisp commented Feb 12, 2025

Reverted logic for optional repre['ext'].

@kalisp kalisp requested a review from iLLiCiTiT February 12, 2025 16:30
@kalisp kalisp merged commit 8228974 into develop Feb 12, 2025
1 check passed
@kalisp kalisp deleted the bugfix/AY-7453_Deadline-product-ending-with-_1-confuses-expected-files-validator branch February 12, 2025 17:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sponsored This is directly sponsored by a client or community member type: bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants