Harden logger production compliance

[vishalanandl177]

Summary

This PR has been rebuilt from main and contains the production hardening/compliance changes, the package version bump to 1.2.1, and a GitHub Actions workflow for PyPI publishing.

• Aligns README/Sphinx settings documentation with the supported DRF API Logger keys, including DRF_API_LOGGER_CUSTOM_HANDLER and DRF_API_LOGGER_PROFILING_SAMPLE_RATE.
• Hardens sensitive-data masking for headers, query parameters, and nested payloads with case-insensitive hyphen/underscore matching.
• Moves queue threshold handling out of the request path, adds worker shutdown/status accounting, and prevents signal-listener failures from breaking logging.
• Adds default request/response body capture limits, truncation markers, content-type normalization, profiling sampling, and SQL cursor restoration on exceptions.
• Adds a compliance readiness guide covering minimization, redaction, storage controls, retention, profiling controls, and operational monitoring.
• Adds .github/workflows/publish.yml to test/build packages and publish to PyPI from main using Trusted Publishing.

Validation

• J:\projects\drf-demo\venv\Scripts\python.exe -m django test tests.test_utils tests.test_middleware tests.test_signals tests.test_profiling tests.test_backward_compat --settings=tests.test_settings --verbosity=1 - 111 tests OK
• J:\projects\drf-demo\venv\Scripts\python.exe -m django test tests --settings=tests.test_settings --verbosity=1 - 142 tests OK
• git diff --check - OK
• git diff --cached --check before workflow commit - OK
• python setup.py --name returned drf-api-logger
• python setup.py --version returned 1.2.1
• Workflow content check confirmed the expected test, build, metadata validation, OIDC, and PyPI publish steps are present.
• Settings-key comparison found no code keys missing from README or Sphinx docs.

Publish Behavior

The workflow runs tests and builds package artifacts for PRs and pushes. It publishes only when running on refs/heads/main, uses the pypi GitHub environment, requests id-token: write, checks that the package version is not already on PyPI, then uses pypa/gh-action-pypi-publish@release/v1.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1bea170a45

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Mask form-encoded request bodies before logging

When a request uses Content-Type: application/x-www-form-urlencoded, this branch now returns the raw decoded body (for example password=secret&token=abc), but the later call is mask_sensitive_data(request_data) without mask_api_parameters=True, so string bodies are stored/emitted unchanged. This contradicts the new compliance/security docs that sensitive body keys are masked before database or signal delivery and leaks common form secrets whenever the response content type is logged.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Include metrics and OTel in the middleware gate

With only DRF_API_LOGGER_ENABLE_METRICS=True or only DRF_API_LOGGER_ENABLE_OTEL=True (the README documents both as standalone settings), this guard is false unless database logging or signals are also enabled, so the middleware jumps straight to get_response() and never records metrics or starts/finishes spans. Users following the new metrics/OTel setup without also enabling DRF_API_LOGGER_SIGNAL/DRF_API_LOGGER_DATABASE get empty metrics and no traces.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Finish owned OTel spans when views raise

If OTel is enabled and get_response() raises an unhandled exception after start_span() created an owned span, this except immediately re-raises and the later finish_span(..., otel_span_owned, ...) call is skipped. In that scenario the span is never ended/exported and the error is not reflected in tracing; wrap the view call/logging path so owned spans are ended in a finally even on exceptions.

Useful? React with 👍 / 👎.