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

[IMP] queue_job: Don't raise a warning for valid context #679

Merged
merged 1 commit into from
Oct 9, 2024

Conversation

rousseldenis
Copy link
Contributor

As the 'queue_job__no_delay' context key is the valid one to use, don't raise warnings during tests, but log it as information level.

@simahawk Warning level should be only used to show something that could goes wrong (e.g.: deprecated methods, wrong definitions, ...). In this case, the use of the correct key context should not raise a warning and log as information only.

As I try to keep an eye on real warnings, they are lost in the crowd like:

https://github.com/OCA/sale-workflow/actions/runs/10522761814/job/29156065217#step:8:3025

@OCA-git-bot
Copy link
Contributor

Hi @guewen,
some modules you are maintaining are being modified, check this out!

Copy link
Member

@guewen guewen left a comment

Choose a reason for hiding this comment

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

Maybe it should be logged as warning if test_enable is not set? (e.g. run on production). That was maybe the original intent?

@rousseldenis
Copy link
Contributor Author

Maybe it should be logged as warning if test_enable is not set? (e.g. run on production). That was maybe the original intent?

And if we really want (I don't do it) to run without delay ? I think this could be done without warnings.

Copy link
Contributor

@amh-mw amh-mw left a comment

Choose a reason for hiding this comment

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

LGTM, but adding the test_enable check would be superior.

@OCA-git-bot
Copy link
Contributor

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

@rousseldenis
Copy link
Contributor Author

@simahawk Your review on this would be welcome. Thanks

@rousseldenis
Copy link
Contributor Author

@guewen @amh-mw Adapted to warn if not testing.

@simahawk
Copy link
Contributor

simahawk commented Sep 10, 2024

Maybe it should be logged as warning if test_enable is not set? (e.g. run on production). That was maybe the original intent?

AFAIR yes :)

And if we really want (I don't do it) to run without delay ? I think this could be done without warnings.

AFAIR I was thinking of this as well.

Thinking again about this right now: in fact, if you do it explicitly there's no reason to log a warning no matter if in tests or in prod mode. IMO we can skip the distinction and always log the same info message.

@rousseldenis
Copy link
Contributor Author

Thinking again about this right now: in fact, if you do it explicitly there's no reason to log a warning no matter if in tests or in prod mode. IMO we can skip the distinction and always log the same info message.

Indeed, putting it in the context is sufficient

@amh-mw
Copy link
Contributor

amh-mw commented Sep 16, 2024

Thinking again about this right now: in fact, if you do it explicitly there's no reason to log a warning no matter if in tests or in prod mode. IMO we can skip the distinction and always log the same info message.

I'm good with never warning.

@rousseldenis
Copy link
Contributor Author

So, just one info message if context used, correct (I need to change this PR) ?

As the 'queue_job__no_delay' context key is the valid one to use,
don't raise warnings during tests, but log it as information level.
self.env["test.queue.job"]
.with_context(_job_force_sync=True)
.delay_me(1, kwarg=2)
with self.assertLogs(level="WARNING") as log_catcher:
Copy link
Contributor

Choose a reason for hiding this comment

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

this test needs an update no?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@simahawk
Copy link
Contributor

simahawk commented Oct 9, 2024

/ocabot merge patch

@OCA-git-bot
Copy link
Contributor

What a great day to merge this nice PR. Let's do it!
Prepared branch 16.0-ocabot-merge-pr-679-by-simahawk-bump-patch, awaiting test results.

@OCA-git-bot OCA-git-bot merged commit 868f614 into OCA:16.0 Oct 9, 2024
7 checks passed
@OCA-git-bot
Copy link
Contributor

Congratulations, your PR was merged at f91aced. Thanks a lot for contributing to OCA. ❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants