google / google/secops-wrapper
Use warning logging instead of stderr print for HTTP retries
- Dominant language
- Python
- Stars
- 92
- Forks
- 48
- PR merge metrics
- No merged PRs in 30d
Description
## Problem
`LogRetry.increment()` writes retry diagnostics directly to `sys.stderr` with `print()`:
```python
if response:
print(
f"Retrying {method} {url} for {response.status} status code....",
file=sys.stderr,
)
else:
print(
f"Retrying {method} {url} due to error: {error}",
file=sys.stderr,
)
```
When application logs are collected and sent to Datadog, this raw stderr output can be buffered together with neighboring application logs. Because it bypasses Python logging, the retry message has no standard log level or logger metadata, which causes discrepancies in downstream log parsing.
## Impact
- Retry messages may be grouped with unrelated log records in Datadog.
- Log parsers cannot consistently identify the retry event or its severity.
- SDK users cannot control these messages through their normal Python logging configuration.
## Proposed change
Use a module logger and emit retry events at warning level:
```python
import logging
logger = logging.getLogger(__name__)
if response:
logger.warning(
f"Retrying {method} {url} for {response.status} status code...."
)
else:
logger.warning(
f"Retrying {method} {url} due to error: {error}"
)
```
A retry is recoverable, but it represents an abnormal request path, so `WARNING` communicates the event without treating it as a terminal failure. The SDK should not configure logging itself; callers should retain control of handlers and formatting.
## Acceptance criteria
- `LogRetry.increment()` no longer writes retry diagnostics directly to stderr.
- Response-triggered and error-triggered retries emit a `WARNING` through Python logging.
- Tests cover both retry-message paths using log capture.
- Existing retry behavior and retry counters remain unchanged.
Feedback on this approach is welcome before implementation.
Contributor guide
Research direction
Start by reading LogRetry.increment() and locating the surrounding retry tests. Replace its stderr diagnostics with warning-level Python logging for both response and error paths, then verify through log capture that retry behavior and counters remain unchanged.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- api
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 76/100