nene2-python 1.8.15__tar.gz → 1.8.17__tar.gz

{nene2_python-1.8.15 → nene2_python-1.8.17}/CHANGELOG.md

@@ -5,6 +5,33 @@ Format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
 ---
 
+## [1.8.17] — 2026-05-20
+
+FT64 フィールドトライアル — ValidationException 複数エラー実運用検証。
+
+### Fixed
+- `ValidationError.code` にスペースが含まれる場合 `ValueError` を発生させるよう修正 — `message` と `code` の混同を早期検出できるようになった (#300) (FT64)
+
+### Changed
+- `ValidationError` と `ValidationException.single()` の docstring を改善 — `message` (人間可読) と `code` (機械可読 snake_case) の違いをキーワード引数付き例で明示 (#300) (FT64)
+
+### Added
+- Field trial report: `docs/field-trials/2026-05-field-trial-64.md`
+
+---
+
+## [1.8.16] — 2026-05-20
+
+FT63 フィールドトライアル — configure_problem_details 実運用検証 + PROBLEM_DETAILS_BASE_URL エクスポート修正。
+
+### Fixed
+- `PROBLEM_DETAILS_BASE_URL` 定数を `nene2.http` からエクスポートするよう修正 — テストで `from nene2.http import PROBLEM_DETAILS_BASE_URL` が利用可能になった (#296) (FT63)
+
+### Added
+- Field trial reports: `docs/field-trials/2026-05-field-trial-56.md` 〜 `2026-05-field-trial-63.md` (FT56〜FT63)
+
+---
+
 ## [1.8.15] — 2026-05-20
 
 FT55 フィールドトライアル — parse_db_datetime 実運用検証。

{nene2_python-1.8.15 → nene2_python-1.8.17}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: nene2-python
-Version: 1.8.15
+Version: 1.8.17
 Summary: NENE2 Python — minimal API framework following NENE2's design philosophy
 Project-URL: Homepage, https://github.com/hideyukiMORI/nene2-python
 Project-URL: Repository, https://github.com/hideyukiMORI/nene2-python

nene2_python-1.8.17/docs/field-trials/2026-05-field-trial-56.md

@@ -0,0 +1,50 @@
+# FT56: CompositeHealthCheck + http_status_code 実運用検証
+
+**日付**: 2026-05-20  
+**テーマ**: 同期ヘルスチェック集約 (`CompositeHealthCheck`) と `HealthStatus.http_status_code` の実運用確認  
+**バージョン**: v1.8.15  
+**FTディレクトリ**: `/home/xi/docker/nene2-python-FT/ft56-health-check/`
+
+---
+
+## 概要
+
+`nene2.http.CompositeHealthCheck` と `HealthStatus.http_status_code` を FastAPI ルートに組み込み、
+複数の依存サービス（DB・キャッシュ）のヘルスチェックを集約するパターンを検証した。
+
+---
+
+## 実装内容
+
+- `DatabaseHealthCheck` / `CacheHealthCheck`: `HealthCheckProtocol` 実装クラス
+- `CompositeHealthCheck([db, cache])`: 集約チェック
+- `/health` エンドポイント: 結果を `status_code=status.http_status_code` で返却
+
+---
+
+## テスト結果
+
+**7/7 passed**
+
+| テスト | 結果 |
+|---|---|
+| `test_all_healthy_returns_200` | PASSED |
+| `test_db_unhealthy_returns_503` | PASSED |
+| `test_cache_unhealthy_returns_503` | PASSED |
+| `test_both_unhealthy_returns_503` | PASSED |
+| `test_health_status_http_status_code_ok` | PASSED |
+| `test_health_status_http_status_code_error` | PASSED |
+| `test_composite_merges_checks` | PASSED |
+
+---
+
+## Friction Points
+
+なし。`CompositeHealthCheck` は直感的なインターフェースで、ドキュメントどおりに動作した。
+
+---
+
+## 結論
+
+`CompositeHealthCheck` は実運用で問題なく使用できる。
+`http_status_code` プロパティにより、FastAPI の `JSONResponse` に直接渡せるのが便利。

nene2_python-1.8.17/docs/field-trials/2026-05-field-trial-57.md

@@ -0,0 +1,50 @@
+# FT57: AsyncCompositeHealthCheck 実運用検証
+
+**日付**: 2026-05-20  
+**テーマ**: 非同期ヘルスチェック集約 (`AsyncCompositeHealthCheck`) と並列実行の実運用確認  
+**バージョン**: v1.8.15  
+**FTディレクトリ**: `/home/xi/docker/nene2-python-FT/ft57-async-health/`
+
+---
+
+## 概要
+
+`nene2.http.AsyncCompositeHealthCheck` を FastAPI の async ルートに組み込み、
+複数の依存サービス（DB・外部API）のヘルスチェックを `asyncio.gather` で並列実行するパターンを検証した。
+
+---
+
+## 実装内容
+
+- `AsyncDatabaseHealthCheck` / `AsyncExternalApiHealthCheck`: `AsyncHealthCheckProtocol` 実装クラス（`async def check()`）
+- `AsyncCompositeHealthCheck([db, api])`: `asyncio.gather` による並列集約
+- `/health` エンドポイント: `async def health()` で `await composite.check()` を呼び出し
+- 並列実行タイミングテスト: 各 50ms のチェック2つが 90ms 未満で完了することを確認
+
+---
+
+## テスト結果
+
+**5/5 passed**
+
+| テスト | 結果 |
+|---|---|
+| `test_all_healthy_returns_200` | PASSED |
+| `test_db_unhealthy_returns_503` | PASSED |
+| `test_api_unhealthy_returns_503` | PASSED |
+| `test_both_unhealthy_returns_503` | PASSED |
+| `test_parallel_execution_is_faster` | PASSED |
+
+---
+
+## Friction Points
+
+なし。`AsyncCompositeHealthCheck` は直感的なインターフェースで、並列実行も確認できた。
+`pytest-asyncio` の `asyncio_mode = "auto"` 設定で `async def test_*` がそのまま動作した。
+
+---
+
+## 結論
+
+`AsyncCompositeHealthCheck` は実運用で問題なく使用できる。
+`asyncio.gather` による並列実行は計測でも確認でき、直列実行比で約2倍の高速化が得られた。

nene2_python-1.8.17/docs/field-trials/2026-05-field-trial-58.md

@@ -0,0 +1,60 @@
+# FT58: ThrottleMiddleware 実運用検証
+
+**日付**: 2026-05-20  
+**テーマ**: レートリミットミドルウェア (`ThrottleMiddleware`) の実運用確認  
+**バージョン**: v1.8.15  
+**FTディレクトリ**: `/home/xi/docker/nene2-python-FT/ft58-throttle/`
+
+---
+
+## 概要
+
+`nene2.middleware.ThrottleMiddleware` を FastAPI に組み込み、
+グローバルレート制限・エンドポイント別制限・除外パス・レートヘッダーを検証した。
+
+---
+
+## 実装内容
+
+- `ThrottleMiddleware(limit=N, window=60)`: グローバルレート制限
+- `path_limits={"/api/expensive": 2}`: エンドポイント別に厳しい制限
+- `exclude_paths=["/health"]`: ヘルスチェックをレート制限から除外
+- レスポンスヘッダー確認: `X-RateLimit-Limit`, `X-RateLimit-Remaining`, `X-RateLimit-Reset`, `Retry-After`
+
+---
+
+## テスト結果
+
+**9/9 passed**
+
+| テスト | 結果 |
+|---|---|
+| `test_under_limit_returns_200` | PASSED |
+| `test_rate_limit_headers_present` | PASSED |
+| `test_remaining_decrements_per_request` | PASSED |
+| `test_exceeding_limit_returns_429` | PASSED |
+| `test_429_includes_retry_after_header` | PASSED |
+| `test_exclude_paths_bypass_throttle` | PASSED |
+| `test_path_limits_stricter_than_global` | PASSED |
+| `test_path_limits_independent_from_global` | PASSED |
+| `test_429_response_is_problem_details` | PASSED |
+
+---
+
+## Friction Points
+
+なし。`ThrottleMiddleware` はすべての機能が直感的に動作した。
+
+**特筆点**:
+- `path_limits` のカウンターがグローバルカウンターと独立しているのは設計どおりで便利
+- `exclude_paths` でヘルスチェックを除外できるのは本番運用で必須の機能
+- 429 レスポンスが RFC 9457 Problem Details 形式なのは一貫性がある
+- `Retry-After` ヘッダーが自動付与される点がクライアント実装に優しい
+
+---
+
+## 結論
+
+`ThrottleMiddleware` は実運用で問題なく使用できる。
+`X-Forwarded-For` の信頼に関するドキュメントの警告も適切で、
+リバースプロキシなし環境での注意点が明記されている。

nene2_python-1.8.17/docs/field-trials/2026-05-field-trial-59.md

@@ -0,0 +1,62 @@
+# FT59: SecurityHeadersMiddleware 実運用検証
+
+**日付**: 2026-05-20  
+**テーマ**: セキュリティヘッダーミドルウェア (`SecurityHeadersMiddleware`) の実運用確認  
+**バージョン**: v1.8.15  
+**FTディレクトリ**: `/home/xi/docker/nene2-python-FT/ft59-security-headers/`
+
+---
+
+## 概要
+
+`nene2.middleware.SecurityHeadersMiddleware` を FastAPI に組み込み、
+デフォルトヘッダー・CSP・HSTS・除外パス設定を検証した。
+
+---
+
+## 実装内容
+
+- デフォルト設定でのセキュリティヘッダー確認
+- カスタム CSP / Permissions-Policy の適用
+- HSTS ヘッダーの条件付き付与（デフォルト無効、本番向け）
+- `/docs`, `/redoc`, `/openapi.json` での CSP 自動スキップ
+- `extra_no_csp_paths` によるカスタムパスの CSP 除外
+
+---
+
+## テスト結果
+
+**10/10 passed**
+
+| テスト | 結果 |
+|---|---|
+| `test_default_static_headers_present` | PASSED |
+| `test_default_csp_applied` | PASSED |
+| `test_default_permissions_policy_applied` | PASSED |
+| `test_hsts_not_set_by_default` | PASSED |
+| `test_hsts_applied_when_configured` | PASSED |
+| `test_csp_skipped_for_docs_paths` | PASSED |
+| `test_custom_csp_applied` | PASSED |
+| `test_custom_permissions_policy_applied` | PASSED |
+| `test_extra_no_csp_paths_skip_csp` | PASSED |
+| `test_extra_no_csp_paths_does_not_affect_other_paths` | PASSED |
+
+---
+
+## Friction Points
+
+なし。`SecurityHeadersMiddleware` はすべての機能が直感的に動作した。
+
+**特筆点**:
+- OpenAPI パス (`/docs`, `/redoc`, `/openapi.json`) での CSP 自動スキップは、
+  Swagger UI の CDN アセット読み込みが壊れないよう配慮されており実用的
+- HSTS がデフォルト無効なのは開発環境を壊さないための正しい設計
+- `extra_no_csp_paths` でカスタムドキュメントパスも対応できる柔軟性がある
+
+---
+
+## 結論
+
+`SecurityHeadersMiddleware` は実運用で問題なく使用できる。
+デフォルト設定のみで OWASP 推奨の主要ヘッダーが付与され、
+本番環境では `hsts` パラメータを追加するだけでよい。

nene2_python-1.8.17/docs/field-trials/2026-05-field-trial-60.md

@@ -0,0 +1,57 @@
+# FT60: RequestIdMiddleware 実運用検証
+
+**日付**: 2026-05-20  
+**テーマ**: リクエストIDミドルウェア (`RequestIdMiddleware`) と `get_request_id()` の実運用確認  
+**バージョン**: v1.8.15  
+**FTディレクトリ**: `/home/xi/docker/nene2-python-FT/ft60-request-id/`
+
+---
+
+## 概要
+
+`nene2.middleware.RequestIdMiddleware` を FastAPI に組み込み、
+UUID v4 の自動生成・クライアント指定 ID の転送・不正 ID の置き換え・
+`get_request_id()` による Depends 経由でのアクセスを検証した。
+
+---
+
+## 実装内容
+
+- `RequestIdMiddleware`: X-Request-Id ヘッダーの自動付与
+- `get_request_id()`: `Depends` 経由でルートハンドラーからリクエストID取得
+- クライアント供給 UUID v4 → そのまま転送（小文字正規化）
+- クライアント供給不正値 → サーバー生成 UUID v4 に置き換え
+
+---
+
+## テスト結果
+
+**7/7 passed**
+
+| テスト | 結果 |
+|---|---|
+| `test_response_has_x_request_id_header` | PASSED |
+| `test_generated_request_id_is_uuid_v4` | PASSED |
+| `test_client_supplied_valid_uuid_v4_is_forwarded` | PASSED |
+| `test_client_supplied_invalid_id_is_replaced` | PASSED |
+| `test_request_id_accessible_via_depends` | PASSED |
+| `test_request_id_in_depends_matches_response_header` | PASSED |
+| `test_each_request_gets_unique_id` | PASSED |
+
+---
+
+## Friction Points
+
+なし。`RequestIdMiddleware` と `get_request_id()` はすべて直感的に動作した。
+
+**特筆点**:
+- 不正な X-Request-Id（UUIDv4 以外）は自動で置き換えられ、ログインジェクション対策が組み込まれている
+- `get_request_id()` は `Depends` で使えるため、structlog のコンテキスト設定と自然に組み合わせられる
+- Depends で取得した値とレスポンスヘッダーの値が常に一致することを確認
+
+---
+
+## 結論
+
+`RequestIdMiddleware` は実運用で問題なく使用できる。
+セキュリティ（不正 ID の拒否）と利便性（Depends 連携）の両立が優れている。

nene2_python-1.8.17/docs/field-trials/2026-05-field-trial-61.md

@@ -0,0 +1,58 @@
+# FT61: AsyncUseCaseProtocol 実運用検証
+
+**日付**: 2026-05-20  
+**テーマ**: 非同期ユースケース (`AsyncUseCaseProtocol`) の実運用確認  
+**バージョン**: v1.8.15  
+**FTディレクトリ**: `/home/xi/docker/nene2-python-FT/ft61-async-usecase/`
+
+---
+
+## 概要
+
+`nene2.use_case.AsyncUseCaseProtocol` を実装したユースケースを FastAPI の async ルートに組み込み、
+プロトコル適合・実行時 coroutine 確認・ValidationException 連携を検証した。
+
+---
+
+## 実装内容
+
+- `FetchUserUseCase`: `AsyncUseCaseProtocol[FetchUserInput, FetchUserOutput]` を満たす実装
+- `async def execute(input_)`: asyncio.sleep で非同期 I/O を模擬
+- `ValidationException.single()` で特定 ID の場合に 422 を返す
+- 静的型チェック用のアダプター関数でプロトコル適合を明示
+
+---
+
+## テスト結果
+
+**7/7 passed**
+
+| テスト | 結果 |
+|---|---|
+| `test_fetch_user_returns_200` | PASSED |
+| `test_fetch_nonexistent_user_returns_422` | PASSED |
+| `test_use_case_satisfies_protocol` | PASSED |
+| `test_execute_is_coroutine_function` | PASSED |
+| `test_execute_returns_correct_output` | PASSED |
+| `test_execute_raises_on_fail_ids` | PASSED |
+| `test_multiple_users_independent` | PASSED |
+
+---
+
+## Friction Points
+
+なし。`AsyncUseCaseProtocol` はプロトコル適合・FastAPI async ルート連携ともに直感的に動作した。
+
+**特筆点**:
+- `isinstance(use_case, AsyncUseCaseProtocol)` は `execute` 属性の有無のみチェックするため、
+  sync/async 区別は `inspect.iscoroutinefunction()` で補完する必要がある（ADR-0010 で既知）
+- `ValidationException.single()` から 422 Problem Details への変換は
+  `ErrorHandlerMiddleware` が自動で処理する
+- `@runtime_checkable` プロトコルを使った型引数付き型ヒントでも mypy --strict が通る
+
+---
+
+## 結論
+
+`AsyncUseCaseProtocol` は実運用で問題なく使用できる。
+FastAPI の async ルートと自然に組み合わせられ、ドメインロジックを HTTP 層から分離する設計が機能している。

nene2_python-1.8.17/docs/field-trials/2026-05-field-trial-62.md

@@ -0,0 +1,57 @@
+# FT62: RequestLoggingMiddleware 実運用検証
+
+**日付**: 2026-05-20  
+**テーマ**: リクエストロギングミドルウェア (`RequestLoggingMiddleware`) の実運用確認  
+**バージョン**: v1.8.15  
+**FTディレクトリ**: `/home/xi/docker/nene2-python-FT/ft62-request-logging/`
+
+---
+
+## 概要
+
+`nene2.middleware.RequestLoggingMiddleware` を FastAPI に組み込み、
+structlog コンテキスト変数の設定・除外パス・extra_context・RequestIdMiddleware との連携を検証した。
+
+---
+
+## 実装内容
+
+- `RequestLoggingMiddleware(exclude_paths=["/health"])`: ヘルスチェックをログ除外
+- `extra_context={"service": "ft62"}`: リクエストログへのカスタムフィールド追加
+- `RequestIdMiddleware` と組み合わせてリクエストIDのログへの自動バインド
+- structlog プロセッサをカスタマイズしてログ出力をキャプチャして確認
+
+---
+
+## テスト結果
+
+**6/6 passed**
+
+| テスト | 結果 |
+|---|---|
+| `test_request_passes_through_logging_middleware` | PASSED |
+| `test_excluded_path_still_returns_200` | PASSED |
+| `test_non_excluded_path_passes_normally` | PASSED |
+| `test_extra_context_does_not_break_requests` | PASSED |
+| `test_structlog_context_vars_populated_during_request` | PASSED |
+| `test_logging_middleware_with_request_id_middleware` | PASSED |
+
+---
+
+## Friction Points
+
+なし。`RequestLoggingMiddleware` はすべての機能が直感的に動作した。
+
+**特筆点**:
+- structlog の `merge_contextvars` プロセッサで、ミドルウェアがバインドしたコンテキストが
+  アプリコード側のログにも自動で引き継がれる設計が強力
+- `RequestIdMiddleware` と組み合わせると `request_id` がすべてのログに自動付与される
+- `configure_for_testing()` を使うと structlog の設定がテスト向けに上書きされるため、
+  structlog のカスタムプロセッサをテスト内で設定しなおす必要がある点は把握が必要
+
+---
+
+## 結論
+
+`RequestLoggingMiddleware` は実運用で問題なく使用できる。
+`RequestIdMiddleware` と組み合わせて使うのが推奨パターン。

nene2_python-1.8.17/docs/field-trials/2026-05-field-trial-63.md

@@ -0,0 +1,61 @@
+# FT63: configure_problem_details / PROBLEM_DETAILS_BASE_URL 実運用検証
+
+**日付**: 2026-05-20  
+**テーマ**: Problem Details 設定 API (`configure_problem_details`, `PROBLEM_DETAILS_BASE_URL`) の実運用確認  
+**バージョン**: v1.8.15 → v1.8.16 (修正含む)  
+**FTディレクトリ**: `/home/xi/docker/nene2-python-FT/ft63-problem-details-config/`
+
+---
+
+## 概要
+
+`nene2.http.configure_problem_details()` でプロジェクト全体の base_url を設定し、
+RFC 9457 Problem Details レスポンスの `type` フィールドを自社 URL に変更する
+パターンを検証した。
+
+---
+
+## 実装内容
+
+- `configure_problem_details("https://api.example.com/errors/")`: アプリ起動時にグローバル設定
+- `reset_problem_details()`: テスト間のリセット（autouse fixture）
+- per-call `base_url` 引数がグローバル設定より優先されることを確認
+- `ValidationException` 経由の 422 でも configured base_url が使われることを確認
+
+---
+
+## テスト結果
+
+**7/7 passed** (v1.8.16 で修正後)
+
+| テスト | 結果 |
+|---|---|
+| `test_default_base_url_in_type_field` | PASSED |
+| `test_custom_base_url_applied_via_configure` | PASSED |
+| `test_custom_base_url_affects_all_problem_details_in_app` | PASSED |
+| `test_reset_problem_details_restores_default` | PASSED |
+| `test_problem_details_structure_is_rfc9457_compliant` | PASSED |
+| `test_validation_exception_uses_configured_base_url` | PASSED |
+| `test_per_call_base_url_overrides_configured` | PASSED |
+
+---
+
+## Friction Points
+
+### FP-1: `PROBLEM_DETAILS_BASE_URL` が `nene2.http` からエクスポートされていない
+
+**発生箇所**: `test_app.py` で `from nene2.http import PROBLEM_DETAILS_BASE_URL` を試みた際
+
+**症状**: `ImportError: cannot import name 'PROBLEM_DETAILS_BASE_URL' from 'nene2.http'`
+
+**影響**: テストコードでデフォルト URL を文字列のハードコードを避けられない。
+定数は `problem_details.py` に定義されているが `__init__.py` に含まれていなかった。
+
+**修正**: `nene2.http.__init__` に `PROBLEM_DETAILS_BASE_URL` を追加 (Issue #296, v1.8.16)
+
+---
+
+## 結論
+
+`configure_problem_details()` は実運用で問題なく使用できる。
+`PROBLEM_DETAILS_BASE_URL` のエクスポート漏れが修正され、テストでの文字列ハードコードを避けられる。

nene2_python-1.8.17/docs/field-trials/2026-05-field-trial-64.md

@@ -0,0 +1,67 @@
+# FT64: ValidationException 複数エラー実運用検証
+
+**日付**: 2026-05-20  
+**テーマ**: 複数フィールドの `ValidationException` 集積と `ValidationError` 実運用確認  
+**バージョン**: v1.8.16 → v1.8.17 (修正含む)  
+**FTディレクトリ**: `/home/xi/docker/nene2-python-FT/ft64-multi-validation/`
+
+---
+
+## 概要
+
+`ValidationException` を使って複数フィールドのバリデーションエラーを集積し、
+一度に 422 レスポンスとして返す実運用パターンを検証した。
+
+---
+
+## 実装内容
+
+- `RegisterUserBody`: username・email・age の 3 フィールドを Pydantic で受け取る
+- `_validate_registration()`: エラーを `list[ValidationError]` に集積して `ValidationException(errors)` を raise
+- 複数エラーが一度に返されること、Problem Details 形式であることを確認
+
+---
+
+## テスト結果
+
+**7/7 passed** (v1.8.17 で修正後)
+
+| テスト | 結果 |
+|---|---|
+| `test_valid_registration_returns_201` | PASSED |
+| `test_single_invalid_email_returns_422` | PASSED |
+| `test_underage_user_returns_422` | PASSED |
+| `test_multiple_errors_returned_at_once` | PASSED |
+| `test_422_response_is_problem_details_format` | PASSED |
+| `test_errors_include_field_message_code` | PASSED |
+| `test_pydantic_validation_error_returns_422` | PASSED |
+
+---
+
+## Friction Points
+
+### FP-1: `ValidationError(field, message, code)` の引数順で `message` と `code` を混同
+
+**発生箇所**: `app.py` で `ValidationError` を直接構築した際
+
+**症状**:
+```python
+# 意図: code="invalid_email"
+ValidationError("email", "invalid_email", "メールアドレスの形式が正しくありません")
+# → message="invalid_email", code="メールアドレスの形式が正しくありません" になってしまう
+```
+
+**原因**: `(field, message, code)` の順序で、短い機械可読コードを先に書きたくなるが
+`message` が先に来るため混同が起きやすい。
+
+**修正**: 
+- `ValidationError.code` にスペースを含む場合 `ValueError` を早期発生させる (v1.8.17)
+- docstring にキーワード引数付き例を追加してどちらが何かを明確化
+
+---
+
+## 結論
+
+`ValidationException` の複数エラー集積パターンは実運用で問題なく使用できる。
+`message` と `code` の混同を防ぐ `ValueError` と docstring 改善により、
+今後は早期にミスに気づけるようになった。

{nene2_python-1.8.15 → nene2_python-1.8.17}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "nene2-python"
-version = "1.8.15"
+version = "1.8.17"
 description = "NENE2 Python — minimal API framework following NENE2's design philosophy"
 readme = "README.md"
 license = {text = "MIT"}

{nene2_python-1.8.15 → nene2_python-1.8.17}/src/nene2/http/__init__.py

@@ -9,6 +9,7 @@ from .health import (
 )
 from .pagination import PaginationQuery, PaginationQueryParser, PaginationResponse
 from .problem_details import (
+    PROBLEM_DETAILS_BASE_URL,
     configure_problem_details,
     problem_details_response,
     reset_problem_details,
@@ -23,6 +24,7 @@ __all__ = [
     "PaginationQuery",
     "PaginationQueryParser",
     "PaginationResponse",
+    "PROBLEM_DETAILS_BASE_URL",
     "configure_problem_details",
     "problem_details_response",
     "reset_problem_details",