goutamadwant opened a new issue, #12842:
URL: https://github.com/apache/seatunnel/issues/12842
## What happened
The Qdrant source and sink both expose the documented `api_key` option, but
`QdrantParameters.buildQdrantClient()` reads the value and builds
`QdrantGrpcClient` without calling `withApiKey`. A job configured with the
correct key therefore cannot read from or write to a Qdrant instance that
requires API-key authentication.
Both connectors use this shared client builder. The current anonymous Qdrant
E2E test does not exercise the option.
## Version and environment
- SeaTunnel `dev` (`3.0.1-SNAPSHOT`) at
`51f553cb45b4b2b37b87f7f654352bc0276daf6b` (before the fix)
- Zeta E2E engine, Java 11
- Qdrant `qdrant/qdrant:v1.15.0`, started with
`QDRANT__SERVICE__API_KEY=seatunnel-test-key` (a disposable test key)
## Reproduction
The authenticated test provisions source and sink collections in Qdrant,
inserts 10 source points, and runs this SeaTunnel configuration:
```hocon
env {
parallelism = 1
job.mode = "BATCH"
}
source {
Qdrant {
collection_name = "source_collection"
host = "qdrantauthe2e"
api_key = "seatunnel-test-key"
schema = {
columns = [
{
name = file_name
type = string
}
{
name = file_size
type = int
}
{
name = my_vector
type = float_vector
}
]
}
}
}
sink {
Qdrant {
collection_name = "sink_collection"
host = "qdrantauthe2e"
api_key = "seatunnel-test-key"
}
}
```
With the regression test added but production code unchanged, the targeted
run was:
```shell
./mvnw -pl seatunnel-e2e/seatunnel-connector-v2-e2e/connector-qdrant-e2e \
-DskipUT -DskipIT=false '-Dit.test=QdrantIT#testQdrantWithApiKey' \
-DfailIfNoTests=false -Dskip.spotless=true verify
```
The SeaTunnel job exited with code 1. Qdrant returned:
```text
UNAUTHENTICATED: Must provide an API key or an Authorization bearer token
```
## Before and after
- **Before:** The example supplies the correct key to both connectors, but
the client sends neither key. The source fails to read, so the job cannot copy
the 10 points.
- **After:** A nonempty configured key is passed to the shared Qdrant gRPC
client builder. The same authenticated source-to-sink job completes and the
sink contains all 10 points. Omitting `api_key` continues to use an anonymous
client; the existing anonymous E2E remains green.
## Scope and compatibility
The proposed change does not add or rename options, change defaults, add
dependencies, or alter public APIs. Sending a nonempty `api_key` is the
intended behavior change; a deployment that relied on a configured key being
silently ignored should remove that value. `use_tls` remains opt-in, so TLS
should be enabled when sending an API key over an untrusted network.
## Validation
- Baseline authenticated E2E: **1 test, 1 failure**, with the Qdrant
`UNAUTHENTICATED` response above.
- With the fix: full `QdrantIT` on Java 11 against local Qdrant v1.15.0: **2
tests, 0 failures** (authenticated and anonymous source-to-sink jobs).
- Scoped connector build and formatting checks passed; the changed diff
passed whitespace checks.
- Not yet validated by full repository CI or against a TLS-enabled Qdrant
endpoint.
Implementation compare branch:
https://github.com/apache/seatunnel/compare/dev...goutamadwant:fix/qdrant-api-key-auth
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
