-
Notifications
You must be signed in to change notification settings - Fork 24
fix: config remap fields component to provide correct config context #608
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
Conversation
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.
Pull Request Overview
This PR updates the remap field transformation to prefer self.config
and fall back to the injected config
when self.config
is empty.
- Use
self.config
in mapping evaluation - Fallback to
config
ifself.config
is falsy
Comments suppressed due to low confidence (2)
airbyte_cdk/sources/declarative/transformations/config_transformations/remap_field.py:62
- Add a unit test for the case where
self.config
is an empty dict to ensure that the code correctly falls back to the injectedconfig
.
mapping = self._map.eval(config=self.config or config)
airbyte_cdk/sources/declarative/transformations/config_transformations/remap_field.py:62
- Using
or
for config fallback can lead to unintended behavior whenself.config
is falsy (e.g., an empty dict). Consider explicitly checking for None:config=self.config if self.config is not None else config
.
mapping = self._map.eval(config=self.config or config)
📝 WalkthroughWalkthroughThe change updates the Changes
Sequence Diagram(s)sequenceDiagram
participant Caller
participant ConfigRemapField
Caller->>ConfigRemapField: transform(config)
alt self.config is truthy
ConfigRemapField->>ConfigRemapField: evaluate mapping with self.config
else
ConfigRemapField->>ConfigRemapField: evaluate mapping with config argument
end
ConfigRemapField-->>Caller: return transformed result
Would it be helpful to add a test case illustrating the new fallback behavior for mapping evaluation, wdyt? ✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. 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
🧹 Nitpick comments (1)
airbyte_cdk/sources/declarative/transformations/config_transformations/remap_field.py (1)
62-62
: Nice fallback implementation!The logic change looks good and aligns perfectly with the PR objective of providing correct config context. Using
self.config or config
provides a clean fallback when the instance config is empty.However, would you consider updating the docstring to document this fallback behavior? Something like mentioning that the mapping evaluation uses the instance config if available, otherwise falls back to the provided config parameter - wdyt?
def transform( self, config: MutableMapping[str, Any], ) -> None: """ Transforms a config by remapping a field value based on the provided map. If the original value is found in the map, it's replaced with the mapped value. If the value is not in the map, the field remains unchanged. + + The mapping evaluation uses the instance's config if available, + otherwise falls back to the provided config parameter. :param config: The user-provided configuration to be transformed """
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
airbyte_cdk/sources/declarative/transformations/config_transformations/remap_field.py
(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (9)
- GitHub Check: Check: source-shopify
- GitHub Check: Check: source-hardcoded-records
- GitHub Check: Check: source-pokeapi
- GitHub Check: Check: source-amplitude
- GitHub Check: Check: source-intercom
- GitHub Check: SDM Docker Image Build
- GitHub Check: Pytest (All, Python 3.11, Ubuntu)
- GitHub Check: Pytest (All, Python 3.10, Ubuntu)
- GitHub Check: Pytest (Fast)
🔇 Additional comments (1)
airbyte_cdk/sources/declarative/transformations/config_transformations/remap_field.py (1)
62-62
: Should we verify existing usage patterns?The change from always using
self.config
toself.config or config
could potentially alter behavior for existing code. Would it be worth verifying how this component is currently used to ensure the fallback doesn't break existing functionality - wdyt?#!/bin/bash # Description: Search for existing usage patterns of ConfigRemapField to understand impact # Expected: Find instantiation patterns and see if self.config is typically set echo "=== Searching for ConfigRemapField usage patterns ===" rg -A 10 -B 5 "ConfigRemapField\(" --type py echo -e "\n=== Searching for config parameter usage in transform calls ===" rg -A 5 -B 5 "\.transform\(" --type py | grep -A 10 -B 10 "ConfigRemapField" echo -e "\n=== Searching for files that import or reference ConfigRemapField ===" rg "ConfigRemapField" --type py
What
Summary by CodeRabbit
Important
Auto-merge enabled.
This PR is set to merge automatically when all requirements are met.