70 lines
2.6 KiB
Markdown
70 lines
2.6 KiB
Markdown
# Auth Service Login Failure Fix
|
|
|
|
## Issue Description
|
|
|
|
The auth service was failing during login with the following error:
|
|
|
|
```
|
|
Session error: Logger._log() got an unexpected keyword argument 'tenant_service_url'
|
|
```
|
|
|
|
This error occurred in the `SubscriptionFetcher` class when it tried to log initialization information using keyword arguments that are not supported by the standard Python logging module.
|
|
|
|
## Root Cause
|
|
|
|
The issue was caused by incorrect usage of the Python logging module. The code was trying to use keyword arguments in logging calls like this:
|
|
|
|
```python
|
|
logger.info("SubscriptionFetcher initialized", tenant_service_url=self.tenant_service_url)
|
|
```
|
|
|
|
However, the standard Python logging module's `_log()` method does not support arbitrary keyword arguments. This is a common misunderstanding - some logging libraries like `structlog` support this pattern, but the standard `logging` module does not.
|
|
|
|
## Files Fixed
|
|
|
|
1. **services/auth/app/utils/subscription_fetcher.py**
|
|
- Fixed `logger.info()` call in `__init__()` method
|
|
- Fixed `logger.debug()` calls in `get_user_subscription_context()` method
|
|
|
|
2. **services/auth/app/services/auth_service.py**
|
|
- Fixed multiple `logger.warning()` and `logger.error()` calls
|
|
|
|
## Changes Made
|
|
|
|
### Before (Problematic):
|
|
```python
|
|
logger.info("SubscriptionFetcher initialized", tenant_service_url=self.tenant_service_url)
|
|
logger.debug("Fetching subscription data for user", user_id=user_id)
|
|
logger.warning("Failed to publish registration event", error=str(e))
|
|
```
|
|
|
|
### After (Fixed):
|
|
```python
|
|
logger.info("SubscriptionFetcher initialized with URL: %s", self.tenant_service_url)
|
|
logger.debug("Fetching subscription data for user: %s", user_id)
|
|
logger.warning("Failed to publish registration event: %s", str(e))
|
|
```
|
|
|
|
## Impact
|
|
|
|
- ✅ Login functionality now works correctly
|
|
- ✅ All logging calls use the proper Python logging format
|
|
- ✅ Error messages are still informative and include all necessary details
|
|
- ✅ No functional changes to the business logic
|
|
- ✅ Maintains backward compatibility
|
|
|
|
## Testing
|
|
|
|
The fix has been verified to:
|
|
1. Resolve the login failure issue
|
|
2. Maintain proper logging functionality
|
|
3. Preserve all error information in log messages
|
|
4. Work with the existing logging configuration
|
|
|
|
## Prevention
|
|
|
|
To prevent similar issues in the future:
|
|
1. Use string formatting (`%s`) for variable data in logging calls
|
|
2. Avoid using keyword arguments with the standard `logging` module
|
|
3. Consider using `structlog` if structured logging with keyword arguments is needed
|
|
4. Add logging tests to CI/CD pipeline to catch similar issues early |