feat: add request visibility controls and option passthrough#320
feat: add request visibility controls and option passthrough#320josevelaz wants to merge 4 commits intoSoju06:mainfrom
Conversation
…ty-ui-toggle # Conflicts: # frontend/src/features/dashboard/components/recent-requests-table.test.tsx # frontend/src/features/dashboard/components/recent-requests-table.tsx
feat: add request visibility controls and option passthrough
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fc94527233
ℹ️ 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".
| return { | ||
| "headers": captured_headers, | ||
| "body": { |
There was a problem hiding this comment.
Enforce max-bytes cap when headers dominate payload
When request visibility capture is enabled, build_request_visibility_document can still return a blob larger than max_bytes if an allowlisted header (for example a very large User-Agent) dominates size, because only body is truncated and the final fallback returns captured_headers unchanged. In that scenario the advertised 16KB cap is bypassed, so repeated requests can write unexpectedly large request_visibility rows and bloat storage/log payloads.
Useful? React with 👍 / 👎.
| request_visibility_duration_minutes=payload.request_visibility_duration_minutes, | ||
| ) | ||
| ) | ||
| except ValueError as exc: |
There was a problem hiding this comment.
Return a visibility-specific validation error code
The settings API now surfaces request-visibility validation failures from SettingsService.update_settings (for example, temporary mode without a duration), but the except ValueError path still maps every such failure to code="invalid_totp_config". This gives clients a misleading machine-readable error for non-TOTP failures, which breaks reliable client-side handling and user messaging for request-visibility settings errors.
Useful? React with 👍 / 👎.
Summary
r- eserve more useful captured metadata under truncation, surface requested
Ive been testing it myself and haven't run into any issues so far
Addresses #291