AMQP Context Tracking connection error handling#2106
Conversation
Signed-off-by: Ibrahim Sani <Ibrahim.Sani@dreamworks.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2106 +/- ##
==========================================
+ Coverage 60.65% 60.86% +0.21%
==========================================
Files 164 164
Lines 20584 20590 +6
Branches 3579 3582 +3
==========================================
+ Hits 12485 12532 +47
+ Misses 7224 7184 -40
+ Partials 875 874 -1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
I like the change, it seems solid overall, but I will just want to wait for @JeanChristopheMorinPerso to comment. @sanikache : Since the cov-bot is basically mostly complaining that nothing hits inside the logging-conf block, I'm wondering if a mocked test-module could hit this codepath without needing an actual AMQP server to hit? |
|
I somehow missed your comment yesterday. That makes sense. I can add a new |
Signed-off-by: Ibrahim Sani <Ibrahim.Sani@dreamworks.com>
|
While running the |
|
That was more of a test than I expected, but I like it. |
| # their logging config, which will leave level != NOTSET here. | ||
| pika_logger = logging.getLogger("rez.vendor.pika") | ||
| if pika_logger.level == logging.NOTSET: | ||
| pika_logger.setLevel(logging.CRITICAL) |
There was a problem hiding this comment.
I'm not sure if we should do that. I feel like if someone provides a logger config file, they are responsible to configure the whole tree. Opinions?
There was a problem hiding this comment.
Sounds reasonable to me.
Signed-off-by: Ibrahim Sani <Ibrahim.Sani@dreamworks.com>
|
Sorry for the late response. I realized I hadn’t pushed the last requested change as I thought, but I’ve just done it now. |
JeanChristopheMorinPerso
left a comment
There was a problem hiding this comment.
I think you are almost there. I think some tests modify the global state, which will impact other tests negatively. This should be addressed before we can merge this PR.
| def _init_logging() -> None: | ||
| logging_conf = os.getenv("REZ_LOGGING_CONF") | ||
| if logging_conf: | ||
| import logging |
There was a problem hiding this comment.
| import logging |
|
|
||
| def test_sets_debug_when_context_tracking_debug_on(self) -> None: | ||
| self.update_settings({"debug_context_tracking": True}) | ||
| set_pika_log_level() |
There was a problem hiding this comment.
This will persist/leak state across other tests. Maybe we could mock the getLogger function to avoid changing the global state?
There was a problem hiding this comment.
Ah! yes, that is correct.
| pika_logger.setLevel(logging.NOTSET) | ||
|
|
||
| with patch.dict(os.environ, {"REZ_LOGGING_CONF": conf_path}): | ||
| _init_logging() |
There was a problem hiding this comment.
If I'm not mistaken, this changes the global state? If so, we should make sure that other tests don't get affected by it.
Signed-off-by: Ibrahim Sani <Ibrahim.Sani@dreamworks.com>
Signed-off-by: Ibrahim Sani <Ibrahim.Sani@dreamworks.com>
@JeanChristopheMorinPerso and I were discussing this over #1968
Pika's vendor library was emitting ERROR-level log messages whenever a broker connection failed, even when context tracking was not configured. This produced spurious output in normal rez usage.
Changes:
init.py: Set rez.vendor.pika logger to CRITICAL at startup, silencing all pika output by default.
amqp.py:
Here's the new behavior with this change after pointing context_tracking_host to a fake host:
To enabling context_tracking to see the full stacktrace: