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

[rousseldenis]

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]

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

[guewen]

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]

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.

[amh-mw]

LGTM, but adding the test_enable check would be superior.

[OCA-git-bot]

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]

@simahawk Your review on this would be welcome. Thanks

[rousseldenis]

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

[simahawk]

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]

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]

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]

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

[simahawk]

this test needs an update no?

[rousseldenis]

Nope, corresponding to true warnings: https://github.com/OCA/queue/pull/679/files#diff-6e33951ef77e0428f3edcd938952cf20d30ca84e703406c08685f3d70d68da86R28

[simahawk]

/ocabot merge patch

[OCA-git-bot]

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]

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