feat(web): add request parse details to workspace tabs

[andrewmelchor]

Summary

This PR implements the display of parsed HTTP request details within the web workspace interface. Previously, the Params, Headers, and Body tabs in the request workspace showed only placeholder text. This change wires up the actual request parsing from the backend and displays the parsed data in structured tables.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e59bff90f6

ℹ️ 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".

[greptile-apps]

Greptile Summary

This PR wires up the backend HTTP parser (postParse) to the three previously-placeholder workspace tabs (Params, Headers, Body), replacing stub text with structured, reactive tables. The implementation is well-structured: a new useRequestParseDetails hook fetches the parse result once per file path (not per request index), and client-side filtering via findRequestBlock handles request switching efficiently. A custom toRequestParams parser handles query strings without relying on the browser URL API, which is appropriate since .http file URLs may be relative or contain template variables.

Key changes:

• use-request-parse-details.ts — new SolidJS resource hook; correctly scopes re-fetching to client+path changes only, filtering by requestIndex client-side
• request-details.ts — utility functions for params, headers, and body summary extraction, with solid edge-case handling (malformed URIs, empty arrays, missing body)
• request-workspace-tabs.tsx — renders all three tabs with loading/error states and typed table layouts
• request-details.test.ts — good coverage across all utility functions including boundary cases

Issue found:

• The hasFormData && hasBodyFile defensive fallback in toRequestBodySummary (line 786) sets description: 'Request includes form data fields and file references.' but omits fields, causing the UI to simultaneously render that description and the "No form-data fields were parsed." fallback — contradictory output for the user.

Confidence Score: 4/5

• Safe to merge with one minor fix — a defensive fallback in toRequestBodySummary produces contradictory UI copy that is straightforward to correct.
• The overall design is clean and well-tested. The single flagged issue is confined to a rarely-reached defensive code path (parsedBody absent while both hasFormData and hasBodyFile are true), so it won't affect most users in practice. No regressions to existing functionality are introduced.
• packages/web/src/utils/request-details.ts — specifically the hasFormData && hasBodyFile defensive fallback at line 786.

Important Files Changed

Filename	Overview
packages/web/src/utils/request-details.ts	New utility with request parsing helpers — toRequestParams, toRequestHeaders, findRequestBlock, and toRequestBodySummary. The hasFormData && hasBodyFile defensive fallback sets a description claiming fields exist but omits fields, producing contradictory UI output.
packages/web/src/components/request-workspace/use-request-parse-details.ts	New SolidJS hook wrapping postParse API call; correctly scopes the resource to path+client (not requestIndex), filtering client-side. Clean design with appropriate error handling.
packages/web/src/components/request-workspace/request-workspace-tabs.tsx	Wires parsed headers, params, and body into structured tables with loading/error states. Logic is sound; inherits the edge-case contradiction from the defensive fallback in request-details.ts.
packages/web/src/components/editor/EditorWithExecution.tsx	Instantiates useRequestParseDetails and threads the four derived signals into RequestWorkspaceTabs as props; clean integration with no new issues.
packages/web/src/utils/request-details.test.ts	Good test coverage for all four utility functions, including edge cases like malformed URIs, empty form-data fields, and missing inline body text.

Sequence Diagram

sequenceDiagram
    participant EWE as EditorWithExecution
    participant Hook as useRequestParseDetails
    participant API as postParse API
    participant Tabs as RequestWorkspaceTabs

    EWE->>Hook: { client, path, requestIndex }
    Hook->>Hook: createMemo(source) — depends on client + path only
    Hook->>API: postParse({ path, includeDiagnostics, includeBodyContent })
    API-->>Hook: ParseRequestDetailsResponse
    Hook->>Hook: findRequestBlock(requests, requestIndex)
    Hook->>Hook: toRequestHeaders(block.request.headers)
    Hook->>Hook: toRequestBodySummary(block.request)
    Hook-->>EWE: { headers(), bodySummary(), loading(), error() }
    EWE->>Tabs: requestHeaders, requestBodySummary, loading, error
    Tabs->>Tabs: toRequestParams(selectedRequest.url) — synchronous
    Tabs-->>EWE: Rendered Params / Headers / Body tabs

Loading

_{Last reviewed commit: ae57f15}

[greptile-apps]

_{7 files reviewed, 5 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Additional Comments (1)

packages/web/src/utils/request-details.ts, line 794
Contradictory UI output for hasFormData && hasBodyFile defensive fallback

This branch returns description: 'Request includes form data fields and file references.' but omits the fields key entirely. In request-workspace-tabs.tsx, the kind === 'form-data' match always evaluates (props.requestBodySummary.fields?.length ?? 0) > 0, which resolves to false when fields is undefined. This causes the <Show> fallback — "No form-data fields were parsed." — to render directly below the description, so the user sees both messages simultaneously:

"Request includes form data fields and file references."
"No form-data fields were parsed."

Since this fallback is reached when parsedBody is absent but both flags are set, the description should be made consistent with the empty-fields UI state:

  if (hasFormData && hasBodyFile) {
    return {
      kind: 'form-data',
      hasBody,
      hasFormData,
      hasBodyFile,
      fields: [],
      description: 'No form-data fields were parsed for this request.'
    };
  }