google / google/secops-wrapper

Use warning logging instead of stderr print for HTTP retries

Open Beginner friendly
#221 0 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.