-
Notifications
You must be signed in to change notification settings - Fork 2
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: update deprecated imports from ovos-utils #36
Conversation
WalkthroughThe changes involve modifications to the Changes
Poem
Warning Rate limit exceeded@JarbasAl has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 15 minutes and 47 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
ovos_messagebus/event_handler.py (1)
66-68
: Improve log message formatting for better readabilityWhile the f-strings are a good improvement, the string concatenation could be more readable.
Consider this format:
- LOG.debug(deserialized_message.msg_type + - f' source: {deserialized_message.context.get("source", [])}' + - f' destination: {deserialized_message.context.get("destination", [])}\n' - f'SESSION: {SessionManager.get(deserialized_message).serialize()}') + LOG.debug( + f"{deserialized_message.msg_type} " + f"source: {deserialized_message.context.get('source', [])} " + f"destination: {deserialized_message.context.get('destination', [])}\n" + f"SESSION: {SessionManager.get(deserialized_message).serialize()}" + )
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
ovos_messagebus/event_handler.py
(2 hunks)
🔇 Additional comments (2)
ovos_messagebus/event_handler.py (2)
20-23
: Verify the new import locations are stable APIs
The migration from ovos_utils.fakebus
to ovos_bus_client.message
aligns with the PR objective to fix deprecated imports. Let's verify these are the canonical import locations.
✅ Verification successful
Import changes are correctly implemented
The verification shows:
- No remaining deprecated imports from
ovos_utils.fakebus
- The new import
from ovos_bus_client.message import Message
is consistently used SessionManager
is correctly imported fromovos_bus_client.session
- No conflicting import patterns were found in the codebase
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the new import locations are widely used in the codebase
# and check for any remaining deprecated imports
# Check for any remaining deprecated imports
echo "Checking for any remaining deprecated imports from ovos_utils.fakebus..."
rg "from ovos_utils.fakebus import"
# Verify the new import pattern is consistent across the codebase
echo "Verifying new import pattern usage..."
rg "from ovos_bus_client.message import Message"
Length of output: 405
Script:
#!/bin/bash
# Let's verify if Message is consistently imported from ovos_bus_client.message
# by checking for any other import patterns of Message class
echo "Checking for other Message import patterns..."
rg "import.*Message" -g "!*.pyc" -g "!*.md"
# Also check if the SessionManager import is consistent
echo -e "\nVerifying SessionManager import pattern..."
rg "import.*SessionManager" -g "!*.pyc" -g "!*.md"
# Check if ovos_bus_client is the main package for these classes
echo -e "\nChecking package structure..."
fd "message.py|session.py" --type f
Length of output: 760
71-71
: Verify the message emission change impact
The change to emit both msg_type and message object might affect existing event listeners.
✅ Verification successful
Let me gather more context about the message handling implementation to understand the impact better.
Let me check one more thing to understand the message deserialization and event handling flow.
Message emission change is backward compatible
Based on the code analysis, the change is safe because:
- When filtering is disabled (
self.filter = False
), the message is emitted directly without modification - When filtering is enabled, the deserialized message object contains both the message type and data, making the new emission pattern compatible with existing handlers
- The event handler implementation shows that listeners are registered with event names that match the message types
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for existing event listeners that might be affected by the emission change
# Look for event listeners in the codebase
echo "Checking for affected event listeners..."
rg "emitter\.on\(" -A 2
Length of output: 275
Script:
#!/bin/bash
# Check the implementation of message handling and event emission
echo "Checking message handling implementation..."
rg "def emit" -A 5
rg "class Message" -A 10
Length of output: 1398
Script:
#!/bin/bash
# Check message deserialization and event handling implementation
echo "Checking message deserialization and event handling..."
rg "def on_message" -A 10
ast-grep --pattern 'class Message {
$$$
}'
Length of output: 920
Summary by CodeRabbit