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

Open
wants to merge 1 commit into
base: 16.0
Choose a base branch
from

Conversation

rousseldenis
Copy link
Sponsor

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
Sponsor 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
Sponsor Author

@simahawk Your review on this would be welcome. Thanks

@rousseldenis
Copy link
Sponsor 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
Sponsor 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
Sponsor 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.
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