Fix Elasticsearch connector configuration key mismatch

[David-Botos]

The Elasticsearch2 query runner was looking for configuration['server'] but BaseHTTPQueryRunner defines the schema field as 'url'. This caused a KeyError that manifested as 'Connection Test Failed: server'.

Fixes #7044

What type of PR is this?

• Bug Fix

Description

Fixed a configuration key mismatch in the Elasticsearch2 query runner that prevented successful connection testing.

Problem:
The ElasticSearch2 query runner in elasticsearch2.py was attempting to access self.configuration["server"], but the BaseHTTPQueryRunner parent class defines this configuration field as "url" in its schema. This mismatch caused a KeyError when attempting to connect, which manifested to users as the error message: Connection Test Failed: 'server'.

Solution:
Updated line 48 in redash/query_runner/elasticsearch2.py to use the correct configuration key:

Before:
url = "{}{}".format(self.configuration["server"], url)

After:
url = "{}{}".format(self.configuration["url"], url)

This aligns the Elasticsearch connector implementation with the configuration schema defined in its parent class BaseHTTPQueryRunner.

Compatibility:
Tested with Elasticsearch 8.18.0. This fix applies to all Elasticsearch versions as it corrects the configuration schema alignment.

How is this tested?

• Manually

Manual Testing Process:

1. Rebuilt the Redash Docker containers with the code changes using make compose_build
2. Configured an Elasticsearch data source with valid connection credentials
3. Clicked "Test Connection" button in the data source configuration UI
4. Verified the connection test now succeeds (previously failed with 'server' error)
5. Confirmed queries execute successfully against the connected Elasticsearch cluster

Related Tickets & Documents

Fixes #7044

Mobile & Desktop Screenshots/Recordings (if there are UI changes)

N/A - This is a backend-only fix with no UI changes.

[cubic-dev-ai]

No issues found across 1 file

[yoshiokatsuneo]

@David-Botos

Thank you for your contribution !

Actually, the issue looks being introduced by the PR . #6899 .

I confirmed that this PR fixed the issue by changing to use the correct "url" setting instead of wrong "server" setting.