HTTP provider fails to work in Continue v1.0.19 and later versions

[neo-rooney]

Before submitting your bug report

I believe this is a bug. I'll try to join the Continue Discord for questions
I'm not able to find an open issue that reports the same bug
I've seen the troubleshooting guide on the Continue Docs

Relevant environment info
Markdown- OS: [Your OS]

• Continue version: 1.0.19+
• IDE version: [Your IDE version]
• Model: qwen3
• config:
  context:
  • provider: http
    params:
    url: http://example.com/api/manual
    title: manual
    displayTitle: 메뉴얼
    description: 메뉴얼을 검색합니다.
    headers:
    Authorization: Bearer [token]
    options: {}

Description
HTTP provider stopped working after upgrading from v1.0.18 to v1.0.19. In v1.0.18, when typing @메뉴얼 (HTTP provider name) in the chat, it would visibly make HTTP requests and fetch data from the configured endpoint. Since v1.0.19, the HTTP provider appears in the chat suggestions but no HTTP communication occurs and no data is retrieved.
The HTTP provider configuration remains unchanged between versions, but the functionality is completely broken in v1.0.19 and later versions.

this is v1.0.18

and this is v1.0.19

[neo-rooney]

Introduction

This is my first time contributing to an open source project, so I'm documenting the problem I encountered and the solution I found. I hope this helps others who might face the same issue.

Problem Overview

After updating to Continue v1.0.19, the HTTP Context Provider stopped returning responses and began returning empty results instead of the expected context items.

Root Cause

1. Missing URI Field Handling

Problem Location: createContextItem function in core/context/providers/HttpContextProvider.ts

Original Code (pre-v1.0.19):

const createContextItem = (item: any) => ({
  description: item.description ?? "HTTP Context Item",
  content: item.content ?? "",
  name: item.name ?? this.options.title ?? "HTTP",
  uri: {
    type: item.uri.type,    // Error when item.uri is null/undefined
    value: item.uri.value,  // Error when item.uri is null/undefined
  },
});

2. Error Handling Flow

1. Server returns JSON response with missing uri field
2. createContextItem(json) attempts to access item.uri.type
3. TypeError: Cannot read property 'type' of null occurs
4. return statement fails to execute
5. catch block returns empty array []

Solution

Fixed Code

const createContextItem = (item: any) => ({
  description: item.description ?? "HTTP Context Item",
  content: item.content ?? "",
  name: item.name ?? this.options.title ?? "HTTP",
  uri: item.uri && {  // Added null check
    type: item.uri.type,
    value: item.uri.value,
  },
});

How the Fix Works

• Conditional Access: item.uri && condition ensures access only when the field exists
• Safe Handling: When item.uri is null, undefined, or false, the uri field becomes undefined
• Backward Compatibility: Works normally even when server doesn't send uri field

Version Differences

Pre-v1.0.19

• Server always sent complete responses with uri field included
• Or JavaScript handled it more leniently

v1.0.19 and Later

• Server responses may have missing or null uri fields
• Strict null checking causes errors

Affected Features

• @manual selection triggers HTTP context provider calls
• Server response processing for LLM delivery
• Context item creation and return

Recommendations

1. Immediate Application: Apply the code fix above to resolve the issue
2. Server Verification: Ensure HTTP server sends consistent response formats
3. Testing: Perform tests with various response formats
4. Documentation: Specify server response format requirements

This fix ensures the HTTP Context Provider works correctly in v1.0.19 and maintains compatibility with different server response formats.

[tomasz-stefaniak]

Thanks @neo-rooney ! I'm marking this as good-first-issue in case anyone wants to make this change. If you decide to work on this fix, please make sure to also write tests that verify that the fix indeed does work.

[sestinj]

🎉 This issue has been resolved in version 1.28.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[sestinj]

🎉 This issue has been resolved in version 1.25.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀