Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Feat : Enable saving intercepted HTTP requests from Edit & Replay modal to API Client#3907

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
Bhogeshwarj wants to merge2 commits intorequestly:master
base:master
Choose a base branch
Loading
fromBhogeshwarj:feature/save-intercept-request

Conversation

@Bhogeshwarj
Copy link
Contributor

@BhogeshwarjBhogeshwarj commentedNov 22, 2025
edited by coderabbitaibot
Loading

Closes issue:#2748

📜 Summary of changes:

This PR introduces the ability to save intercepted HTTP requests from the Edit & Replay modal in the Requestly Desktop App — a feature that previously did not exist.

Key additions include:

  • New Save button in the API Client modal UI when launched from the network interceptor.

  • Initialize and attach a valid API Client persistence context using setupContextWithoutMarkingLoaded, enabling record storage.

  • Saving new intercepted requests using createRecordWithId()

  • Display a success toast after saving.

  • Preserve saved requests across app reloads and modal reopen.

This enhancement enables a smoother workflow where users can now:

Capture → Modify → Replay → Save to API Collection

directly from the desktop HTTP interceptor — without manually recreating the request in the API Client.

🎥 Demo Video:

Screen.Recording.2025-11-22.at.12.56.12.PM.mov

✅ Checklist:

  • Make sure linting and unit tests pass.
  • No install/build warnings introduced.
  • Verified UI in browser.
  • For UI changes, added/updated analytics events (if applicable).
  • For changes in extension's code, manually tested in Chrome and Firefox.
  • Added/updated unit tests for this change.
  • Raised pull request to update corresponding documentation (if already exists).
  • Added demo video showing the changes in action (if applicable).

🧪 Test instructions:

🔗 Other references:

Summary by CodeRabbit

  • New Features

    • API client modal now initializes and uses a dynamic workspace/user context when opened.
  • Improvements

    • Simplified Save button behavior with unified enable/disable logic respecting modal state and unsaved changes.
    • New API requests default to meaningful names ("Untitled request") and preserve collection association when available.
    • Improved error handling and recovery during context initialization.

✏️ Tip: You can customize this high-level summary in your review settings.

@coderabbitai
Copy link
Contributor

coderabbitaibot commentedNov 22, 2025
edited
Loading

Walkthrough

The PR changes API client modal behavior to initialize a runtime API client context when the modal opens. APIClient.tsx adds local state forcontextId, uses Redux selectors for workspace and user, asynchronously callssetupContextWithoutMarkingLoaded, stores the returned id (or falls back toNoopContextId on error), and resetscontextId when the modal closes; rendering is gated until a validcontextId exists and a save callback now closes the modal. HttpClientView.tsx initializes new recordname andcollectionId fromapiEntryDetails (with defaults) and consolidates Save button logic into a singleRBACButton.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

  • APIClient.tsx: async context initialization, lifecycle gating, error handling, and Redux selector usage
  • Modal interaction: ensurecontextId transitions and render guards avoid races
  • HttpClientView.tsx: new defaulting forname/collectionId and the merged Save button conditional logic

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)
Check nameStatusExplanation
Description check✅ PassedThe description covers most required sections including a linked issue, comprehensive summary of changes, demo video, and a populated checklist. However, test instructions are missing/incomplete.
Docstring Coverage✅ PassedNo functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Title check✅ PassedThe title accurately describes the main change: enabling saving of intercepted HTTP requests from the Edit & Replay modal to the API Client, which aligns with the primary objective and code modifications.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

Thanks for usingCodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment@coderabbitai help to get the list of available commands and usage tips.

Copy link
Contributor

@coderabbitaicoderabbitaibot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (1)
app/src/features/apiClient/components/common/APIClient/APIClient.tsx (1)

163-166:Consider adding a loading state during context initialization.

Currently, if the modal is open but the context hasn't finished initializing, nothing is rendered. This could result in a blank modal or jarring user experience if initialization takes noticeable time.

Consider showing a loading indicator:

 // Don't render modal content until context is initialized if (!contextId) {-  return null;+  return (+    <Modal+      className="api-client-modal"+      centered+      title={modalTitle || "API Client"}+      open={isModalOpen}+      onCancel={onModalClose}+      footer={null}+      width="70%"+    >+      <div style={{ display: 'flex', justifyContent: 'center', padding: '2rem' }}>+        <Spin tip="Initializing API Client..." />+      </div>+    </Modal>+  ); }
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between4dcf2b3 ande8039fb.

📒 Files selected for processing (2)
  • app/src/features/apiClient/components/common/APIClient/APIClient.tsx (5 hunks)
  • app/src/features/apiClient/screens/apiClient/components/views/http/HttpClientView.tsx (2 hunks)
🧰 Additional context used
🧠 Learnings (3)
📚 Learning: 2025-10-22T22:57:45.959Z
Learnt from: mustafa-sayyedRepo: requestly/requestly PR: 3723File: app/src/features/apiClient/screens/apiClient/components/views/http/components/HttpRequestTabs/HttpRequestTabs.tsx:146-151Timestamp: 2025-10-22T22:57:45.959ZLearning: In the API Client Scripts tab (app/src/features/apiClient/screens/apiClient/components/views/http/components/HttpRequestTabs/HttpRequestTabs.tsx), the dot indicator should only appear when scripts are present (count > 0). When no scripts exist, the dot should not be rendered. This is the intended behavior per issue #3731.

Applied to files:

  • app/src/features/apiClient/screens/apiClient/components/views/http/HttpClientView.tsx
📚 Learning: 2025-10-05T11:37:16.209Z
Learnt from: nafees87nRepo: requestly/requestly PR: 3625File: app/src/features/apiClient/screens/apiClient/utils.ts:730-731Timestamp: 2025-10-05T11:37:16.209ZLearning: In the requestly codebase's API client feature (app/src/features/apiClient/), HTTP records are the legacy type. GraphQL support was added later, and all GraphQL records always have the `data.type` field set to `RQAPI.ApiEntryType.GRAPHQL`. Therefore, in type guard functions like `isHttpApiRecord` and `isHTTPApiEntry`, if the `type` field is missing, it's safe to assume the record is HTTP. There are no "legacy GraphQL records" without type fields.

Applied to files:

  • app/src/features/apiClient/screens/apiClient/components/views/http/HttpClientView.tsx
📚 Learning: 2025-10-10T08:10:29.153Z
Learnt from: rohanmathur91Repo: requestly/requestly PR: 3658File: app/src/backend/apiClient/batchCreateCollectionRunDetailsInFirebase.ts:29-32Timestamp: 2025-10-10T08:10:29.153ZLearning: In app/src/backend/apiClient/batchCreateCollectionRunDetailsInFirebase.ts, the error path intentionally returns `data: null` rather than an object with `records` and `erroredRecords` arrays. This is a deliberate design decision.

Applied to files:

  • app/src/features/apiClient/screens/apiClient/components/views/http/HttpClientView.tsx
🧬 Code graph analysis (2)
app/src/features/apiClient/components/common/APIClient/APIClient.tsx (5)
app/src/store/slices/workspaces/selectors.ts (1)
  • getActiveWorkspace (31-48)
app/src/store/slices/global/user/selectors.ts (1)
  • getUserAuthDetails (6-8)
app/src/features/apiClient/store/apiClientFeatureContext/apiClientFeatureContext.store.ts (1)
  • NoopContextId (122-122)
app/src/features/apiClient/contexts/contextId.context.tsx (1)
  • ContextId (5-7)
app/src/features/apiClient/store/autogenerateContextProvider.tsx (1)
  • AutogenerateProvider (7-10)
app/src/features/apiClient/screens/apiClient/components/views/http/HttpClientView.tsx (1)
app/src/constants/keyboardShortcuts.ts (1)
  • KEYBOARD_SHORTCUTS (17-64)
🔇 Additional comments (3)
app/src/features/apiClient/screens/apiClient/components/views/http/HttpClientView.tsx (2)

667-669:LGTM! Proper initialization for create mode.

The default values for name and collectionId are appropriate for saving intercepted requests. The empty string fallback for collectionId allows saving uncategorized requests from the network interceptor.


854-869:LGTM! Save button logic correctly adapted for modal usage.

The simplified logic appropriately handles both modal and non-modal contexts:

  • In modal mode: Save button is always enabled (ignoring unsaved changes), which is correct for the interceptor save-as use case.
  • In non-modal mode: Save button is disabled when there are no unsaved changes, preventing unnecessary saves.
  • Keyboard shortcuts are properly restricted to non-modal usage.

The modal automatically closes after save (viahandleSaveCallback), preventing duplicate saves.

app/src/features/apiClient/components/common/APIClient/APIClient.tsx (1)

54-61:LGTM! Proper integration of dynamic context and save callback.

The changes correctly wire up the dynamic API client context and modal close behavior:

  • contextId state properly tracks the initialized context
  • handleSaveCallback is correctly memoized and closes the modal after save
  • TheContextId wrapper uses the dynamiccontextId instead of the staticNoopContextId
  • The callback is properly passed through toClientViewFactory

This enables the intercepted requests to be persisted with a valid API client context.

Also applies to: 181-181, 187-187

@BhogeshwarjBhogeshwarj changed the title Fix: Enable saving intercepted HTTP requests from Edit & Replay modal to API Client Feat : Enable saving intercepted HTTP requests from Edit & Replay modal to API ClientNov 22, 2025
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@coderabbitaicoderabbitai[bot]coderabbitai[bot] left review comments

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Saving requests from HTTP Interceptor to API collection for development

1 participant

@Bhogeshwarj

[8]ページ先頭

©2009-2025 Movatter.jp