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.

Sign up for GitHub

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

Jump to bottom

Fix values check in extra_data #891

Merged
merged 1 commit into from
Mar 7, 2024
Merged

Fix values check in extra_data #891

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion social_core/backends/base.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -146,7 +146,7 @@ def extra_data(self, user, uid, response, details=None, *args, **kwargs):
elif size == 1:
name = alias = entry[0]
discard = False
value = response.get(name) or details.get(name) or details.get(alias)
value = response.get(name, details.get(name, details.get(alias)))
Copy link

@coderabbitai coderabbitai bot Feb 29, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The change in the assignment of value using a nested get method call is intended to fix the bug related to handling integer values in extra_data. However, there's a potential issue with the current implementation:

value = response.get(name, details.get(name, details.get(alias)))

This line attempts to address the bug by using a fallback mechanism for retrieving data. However, the use of details.get(name, details.get(alias)) as the default value in the first get call might not be entirely correct. This approach assumes that details will always have the name or alias keys, which might not be the case, potentially leading to None being assigned to value even when response has a relevant entry.

A more robust solution would be to explicitly check for the presence of keys in response and details and then decide the value of value. This could involve a conditional check or a more nuanced approach to ensure that integer values like 0 are correctly handled and not overridden by None or missed due to the fallback logic not being triggered as expected.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, in the end value can be None, its ok and handled in one line below.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@igorgaming: Thank you for your patience. After reviewing the lines immediately following the modification, it's clear that the code does indeed handle cases where value might be None. The conditional check:

if discard and not value:
    continue

ensures that if discard is True and value is None (or evaluates to False, which includes 0, False, [], etc.), the loop will continue without assigning None to data[alias]. This mechanism effectively addresses the concern about None values being incorrectly processed, aligning with your explanation. It seems the implementation is designed to accommodate None values appropriately, confirming the robustness of the bug fix. Thank you for clarifying this aspect of the code change.

Analysis chain
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Extract the lines immediately following the modified line to understand how `None` values are handled.
sed -n '148,160p' social_core/backends/base.py

Length of output: 697

if discard and not value:
continue
data[alias] = value
Expand Down
Loading