refactor: simplify Responses lifecycle permissions to require explicit per-verb flags and expose them in UI

[Pratham-Mishra04]

Summary

Responses API lifecycle operations (retrieve, delete, cancel, input_items) are now independently gated by their own AllowedRequests flags rather than falling back to the responses (create) flag. Previously, a granular mode was inferred when any lifecycle flag was set, with unset verbs falling back to the responses flag. This change removes that fallback logic and makes each lifecycle verb require its own explicit flag.

Changes

• Removed the granularResponsesLifecycleUsed() helper and the associated fallback logic in IsOperationAllowed. Each of ResponsesRetrieveRequest, ResponsesDeleteRequest, ResponsesCancelRequest, and ResponsesInputItemsRequest now maps directly to its own boolean flag with no inheritance from Responses.
• Removed the test file that covered the now-deleted granular/legacy fallback behavior.
• Added responses_retrieve, responses_delete, responses_cancel, and responses_input_items to the UI's RequestType union, AllowedRequests interface, Zod schema, request type lists, labels, and color mappings.
• Exposed the four new flags in the allowed requests form, defaulting to false for existing providers and true when creating a new custom provider.
• Added a PathOverrideUnsupported set in the allowed requests UI to suppress the path-override control for lifecycle request types, since those paths embed a response ID and a static override cannot produce a valid URL.
• Added the four lifecycle request types to the OpenAI entry in PROVIDER_SUPPORTED_REQUESTS.

Type of change

• Bug fix
• Feature
• Refactor
• Documentation
• Chore/CI

Affected areas

• Core (Go)
• Transports (HTTP)
• Providers/Integrations
• Plugins
• UI (React)
• Docs

How to test

# Core/Transports
go test ./core/schemas/...

# UI
cd ui
pnpm i
pnpm build

Verify that a provider with only responses: true (and no lifecycle flags) now denies retrieve/delete/cancel/input_items requests. Verify that explicitly setting responses_retrieve: true allows retrieve while leaving delete/cancel/input_items denied.

Breaking changes

• Yes
• No

Any existing configuration that relied on responses: true implicitly allowing lifecycle verbs (retrieve, delete, cancel, input_items) will now deny those operations. Operators must explicitly add responses_retrieve, responses_delete, responses_cancel, and/or responses_input_items to their AllowedRequests configuration to restore access.

Security considerations

The change is strictly more restrictive by default. Lifecycle operations that were previously allowed implicitly through the responses flag now require explicit opt-in, reducing the risk of unintended access to stored response data.

Checklist

• I read docs/contributing/README.md and followed the guidelines
• I added/updated tests where appropriate
• I updated documentation where needed
• I verified builds succeed (Go and UI)
• I verified the CI pipeline passes locally if applicable

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[Pratham-Mishra04]

• refactor: simplify Responses lifecycle permissions to require explicit per-verb flags and expose them in UI #4880 👈 (View in Graphite)
• dev

This stack of pull requests is managed by Graphite. Learn more about stacking.

[coderabbitai]

📝 Walkthrough

Summary by CodeRabbit

• New Features

  • Added support for additional response-related request actions in the provider UI and logs.
  • New request options now appear with labels and colors, and can be configured in provider settings.

• Bug Fixes

  • Improved permission handling so response lifecycle actions are controlled individually.
  • Default provider setup now includes the expanded response options, reducing missing-setting issues.

Walkthrough

Backend permission checks for Responses API lifecycle operations (retrieve, delete, cancel, input items) are simplified to evaluate their own granular flags directly, removing fallback logic and a helper method. Frontend types, schemas, constants, and provider forms are extended to support these four new request types, and a related test file is removed.

Changes

Backend permission logic

Layer / File(s)	Summary
Simplify Responses lifecycle authorization core/schemas/provider.go	Removed granularResponsesLifecycleUsed() and simplified IsOperationAllowed so ResponsesRetrieve, ResponsesDelete, ResponsesCancel, and ResponsesInputItems return their own granular boolean directly, with no fallback to the top-level Responses flag; nearby struct fields reformatted only.
Removed granular lifecycle test core/schemas/allowedrequestsresponseslifecycle_test.go	Deleted the test file covering prior fallback-based lifecycle permission behavior.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Frontend granular request type support

Layer / File(s)	Summary
Extend types, schema and constants for new request types ui/lib/types/config.ts, ui/lib/types/schemas.ts, ui/lib/constants/config.ts, ui/lib/constants/logs.ts	RequestType, AllowedRequests, allowedRequestsSchema, PROVIDER_SUPPORTED_REQUESTS.openai, RequestTypes, RequestTypeLabels, and RequestTypeColors are extended with responses_retrieve, responses_delete, responses_cancel, and responses_input_items.
Wire new request types into provider forms and UI ui/app/workspace/providers/dialogs/addNewCustomProviderSheet.tsx, ui/app/workspace/providers/fragments/apiStructureFormFragment.tsx, ui/app/workspace/providers/fragments/allowedRequestsFields.tsx	Form defaults now set the four new responses_* flags, and the allowed-requests UI lists the new request types while disabling path-override customization for them via a new PathOverrideUnsupported set.

Estimated code review effort: 2 (Simple) | ~12 minutes

Sequence Diagram(s)

sequenceDiagram
  participant Client
  participant Server
  participant AllowedRequests

  Client->>Server: request Responses lifecycle operation
  Server->>AllowedRequests: IsOperationAllowed(operation)
  AllowedRequests-->>Server: granular flag value
  Server-->>Client: allow or deny

Loading

Suggested reviewers: danpiths, roroghost17

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main change: explicit Responses lifecycle flags and UI exposure.
Description check	✅ Passed	The description follows the template closely and covers summary, changes, type, affected areas, testing, breaking changes, security, and checklist.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch 07-03-fix_responses_lifecycle_ui_wiring

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 golangci-lint (2.12.2)

level=error msg="[linters_context] typechecking error: pattern ./...: directory prefix . does not contain main module or its selected dependencies"

---

_{Comment @coderabbitai help to get the list of available commands.}

[greptile-apps]

Confidence Score: 4/5

Safe to merge with one gap: the old test file was deleted without replacement, so the new explicit-flag semantics have no automated regression coverage.

The Go logic change is minimal and correct — each lifecycle verb now returns its own dedicated field with no branching. The UI changes are consistent across all touched surfaces (types, schema, constants, form defaults). The only gap is the deleted test file: the new behavior (responses: true alone must deny lifecycle operations) is entirely untested, which could allow a quiet regression in a later refactor.

core/schemas/allowedrequestsresponseslifecycle_test.go — deleted without a replacement that covers the new strict-flag semantics.

Important Files Changed

Filename	Overview
core/schemas/allowedrequestsresponseslifecycle_test.go	Test file deleted entirely; no replacement tests cover the new strict per-verb flag behavior, leaving the behavioral change untested.
core/schemas/provider.go	Removed granularResponsesLifecycleUsed() fallback and simplified IsOperationAllowed to direct field lookups; AllowedRequests struct correctly documents the new nil-means-allow, non-nil-explicit-only semantics.
ui/lib/types/config.ts	Four new lifecycle fields added as optional booleans to RequestType union and AllowedRequests interface, consistent with how ocr/ocr_stream are handled.
ui/app/workspace/providers/fragments/allowedRequestsFields.tsx	New lifecycle types added to RequestTypes list and PathOverrideUnsupported set correctly suppresses the path-override control for request types that embed a response ID.
ui/app/workspace/providers/fragments/apiStructureFormFragment.tsx	Existing-provider edit form correctly defaults the four new flags to false via ?? false, enforcing the opt-in intent of the breaking change.
ui/lib/constants/config.ts	Four lifecycle types added to PROVIDER_SUPPORTED_REQUESTS for OpenAI, enabling the isRequestTypeDisabled check to work correctly in the UI.
ui/lib/constants/logs.ts	RequestTypes list, RequestTypeLabels, and RequestTypeColors updated with four new lifecycle types; colors reuse teal palette matching the parent responses type.
ui/lib/types/schemas.ts	Four lifecycle fields added as optional booleans to the Zod allowedRequestsSchema, consistent with existing optional fields like ocr/ocr_stream.
ui/app/workspace/providers/dialogs/addNewCustomProviderSheet.tsx	New lifecycle flags default to true for new custom providers, consistent with other request types in that path.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[IsOperationAllowed called] --> B{ar == nil?}
    B -- yes --> C[return true]
    B -- no --> D{operation type}

    D -- ResponsesRequest --> E[return ar.Responses]
    D -- ResponsesStreamRequest --> F[return ar.ResponsesStream]
    D -- ResponsesRetrieveRequest --> G[return ar.ResponsesRetrieve]
    D -- ResponsesDeleteRequest --> H[return ar.ResponsesDelete]
    D -- ResponsesCancelRequest --> I[return ar.ResponsesCancel]
    D -- ResponsesInputItemsRequest --> J[return ar.ResponsesInputItems]

    style G fill:#d4edda,stroke:#28a745
    style H fill:#d4edda,stroke:#28a745
    style I fill:#d4edda,stroke:#28a745
    style J fill:#d4edda,stroke:#28a745

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
    A[IsOperationAllowed called] --> B{ar == nil?}
    B -- yes --> C[return true]
    B -- no --> D{operation type}

    D -- ResponsesRequest --> E[return ar.Responses]
    D -- ResponsesStreamRequest --> F[return ar.ResponsesStream]
    D -- ResponsesRetrieveRequest --> G[return ar.ResponsesRetrieve]
    D -- ResponsesDeleteRequest --> H[return ar.ResponsesDelete]
    D -- ResponsesCancelRequest --> I[return ar.ResponsesCancel]
    D -- ResponsesInputItemsRequest --> J[return ar.ResponsesInputItems]

    style G fill:#d4edda,stroke:#28a745
    style H fill:#d4edda,stroke:#28a745
    style I fill:#d4edda,stroke:#28a745
    style J fill:#d4edda,stroke:#28a745

Loading

Comments Outside Diff (1)

1. core/schemas/allowedrequestsresponseslifecycle_test.go

   Missing replacement tests for new behavior

   The deleted file tested the old granular/legacy fallback. No new tests were added to cover the now-in-effect behavior: {Responses: true} alone must deny all four lifecycle verbs, and each verb must be independently gated. Without regression coverage, a future refactor that accidentally restores the old fallback (or inverts the flag semantics) would go undetected. The rules for this repo call for table-driven coverage for behavior changes — this is the behavioral change for AllowedRequests in this PR.

   Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

_{Reviews (1): Last reviewed commit: "fix: responses lifecycle ui wiring" | Re-trigger Greptile}

[coderabbitai]

🧹 Nitpick comments (2)

ui/lib/constants/logs.ts (1)

273-276: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

All four new lifecycle badges share the same color.

responses_retrieve, responses_delete, responses_cancel, and responses_input_items all map to identical teal classes, unlike other sibling groups (e.g., batch_*, video_*) which each get a distinct color for visual differentiation in the logs table.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@ui/lib/constants/logs.ts` around lines 273 - 276, The new lifecycle badge
entries all use the same teal styling, so update the mappings in logs constants
to give responses_retrieve, responses_delete, responses_cancel, and
responses_input_items distinct badge colors similar to other grouped keys like
batch_* and video_*. Adjust the color values in the logs mapping so each
response lifecycle status is visually differentiated in the logs table while
keeping the rest of the constants structure unchanged.

ui/lib/types/schemas.ts (1)

587-621: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Consider matching required-ness of sibling fields.

The new responses_retrieve/delete/cancel/input_items fields are .optional(), while sibling responses/responses_stream are required. Since every current consumer (addNewCustomProviderSheet.tsx, apiStructureFormFragment.tsx) already supplies explicit defaults, making these required would tighten the contract and catch future callers that forget to set a default.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@ui/lib/types/schemas.ts` around lines 587 - 621, The new responses_retrieve,
responses_delete, responses_cancel, and responses_input_items fields in
allowedRequestsSchema are currently optional while sibling response fields are
required. Update allowedRequestsSchema to make these fields required like
responses and responses_stream, and ensure any callers such as
addNewCustomProviderSheet.tsx and apiStructureFormFragment.tsx continue to pass
explicit boolean defaults through the schema contract.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@ui/lib/constants/logs.ts`:
- Around line 273-276: The new lifecycle badge entries all use the same teal
styling, so update the mappings in logs constants to give responses_retrieve,
responses_delete, responses_cancel, and responses_input_items distinct badge
colors similar to other grouped keys like batch_* and video_*. Adjust the color
values in the logs mapping so each response lifecycle status is visually
differentiated in the logs table while keeping the rest of the constants
structure unchanged.

In `@ui/lib/types/schemas.ts`:
- Around line 587-621: The new responses_retrieve, responses_delete,
responses_cancel, and responses_input_items fields in allowedRequestsSchema are
currently optional while sibling response fields are required. Update
allowedRequestsSchema to make these fields required like responses and
responses_stream, and ensure any callers such as addNewCustomProviderSheet.tsx
and apiStructureFormFragment.tsx continue to pass explicit boolean defaults
through the schema contract.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: c6c76ee0-21a0-447e-aa66-cf6c73ed7da1

📥 Commits

Reviewing files that changed from the base of the PR and between 83591ca and 2b16c78.

📒 Files selected for processing (9)

• core/schemas/allowedrequestsresponseslifecycle_test.go
• core/schemas/provider.go
• ui/app/workspace/providers/dialogs/addNewCustomProviderSheet.tsx
• ui/app/workspace/providers/fragments/allowedRequestsFields.tsx
• ui/app/workspace/providers/fragments/apiStructureFormFragment.tsx
• ui/lib/constants/config.ts
• ui/lib/constants/logs.ts
• ui/lib/types/config.ts
• ui/lib/types/schemas.ts

💤 Files with no reviewable changes (1)

• core/schemas/allowedrequestsresponseslifecycle_test.go

[Pratham-Mishra04]

Merge activity

• Jul 3, 10:00 AM UTC: A user started a stack merge that includes this pull request via Graphite.
• Jul 3, 10:01 AM UTC: @Pratham-Mishra04 merged this pull request with Graphite.