-
Notifications
You must be signed in to change notification settings - Fork 1
Description
Summary
The Glean Go SDK's Debug endpoint (sdk.Indexing.Documents.Debug) returns an error "unknown content-type received: application/json" even when the API call succeeds (HTTP 200) and returns valid JSON with the correct Content-Type: application/json header.
Environment
- SDK:
github.com/gleanwork/api-client-gov0.11.30 (also affects v0.11.29) - Endpoint:
POST /api/index/v1/debug/{datasource}/document - Note: The deprecated
Statusendpoint (/api/index/v1/getstatus) does not have this issue
Expected Behavior
When the API returns HTTP 200 with valid JSON and Content-Type: application/json, the SDK should:
- Parse the response successfully
- Return the parsed response object
- Return
nilerror
Actual Behavior
The SDK:
- Makes a successful API call (HTTP 200)
- Returns an error:
unknown content-type received: application/json: Status 200\n{...json response...} - Returns
nilfor the response object (does not populate it)
Reproduction
Using the SDK (demonstrates the bug):
package main
import (
"context"
"fmt"
apiclientgo "github.com/gleanwork/api-client-go"
"github.com/gleanwork/api-client-go/models/components"
)
func main() {
sdk := apiclientgo.New(
apiclientgo.WithInstance("YOUR_INSTANCE"),
apiclientgo.WithSecurity("YOUR_TOKEN"),
)
ctx := context.Background()
req := components.DebugDocumentRequest{
ObjectType: "Document",
DocID: "test-doc-id", // Doesn't need to exist
}
resp, err := sdk.Indexing.Documents.Debug(ctx, "yourdatasourcename", req)
fmt.Printf("Error: %v\n", err)
fmt.Printf("Response: %v\n", resp)
// Output:
// Error: unknown content-type received: application/json: Status 200
// {"status":{"uploadStatus":"NOT_UPLOADED","indexingStatus":"NOT_INDEXED","permissionIdentityStatus":"UPLOADED"},"lifeCycleEvents":[]}
// Response: <nil>
}Raw HTTP Call (demonstrates API works correctly):
curl -X POST \
'https://yourinstance-be.glean.com/api/index/v1/debug/yourdatasourcename/document' \
-H 'Authorization: Bearer YOUR_TOKEN' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-d '{"objectType":"Document","docId":"test-doc-id"}'Response:
HTTP/1.1 200 OK
Content-Type: application/json
{"status":{"uploadStatus":"NOT_UPLOADED","indexingStatus":"NOT_INDEXED","permissionIdentityStatus":"UPLOADED"},"lifeCycleEvents":[]}
Evidence
We created two test programs to verify this behavior:
- test-debug-endpoint.go - Uses the SDK, demonstrates the bug
- test-debug-raw-api.go - Makes raw HTTP call, shows API works correctly
Raw API Response (Correct):
- Status: 200 OK
- Content-Type: application/json
- Body: Valid JSON
SDK Response (Incorrect):
- Error: "unknown content-type received: application/json: Status 200"
- Response Object: nil (not populated)
Root Cause Analysis
File: indexingdocuments.go, line 1226:
case httpRes.StatusCode == 200:
switch {
case utils.MatchContentType(httpRes.Header.Get("Content-Type"), `application/json; charset=UTF-8`):
// Parse JSON response...
default:
// BUG: Falls through to here when Content-Type is "application/json" without charset
return nil, apierrors.NewAPIError(fmt.Sprintf("unknown content-type received: %s",
httpRes.Header.Get("Content-Type")), httpRes.StatusCode, string(rawBody), httpRes)
}The Problem:
- The SDK expects:
application/json; charset=UTF-8 - The API returns:
application/json(without charset parameter) - The
MatchContentTypefunction usesmime.ParseMediaTypewhich should handle this correctly - However, the pattern
application/json; charset=UTF-8doesn't matchapplication/json - When the match fails, it falls through to the
defaultcase which returns an error
Evidence from our raw API test:
Content-Type: application/json
The API is returning the correct content type, but without the charset parameter that the SDK expects.
Suggested Fix
Change line 1226 in indexingdocuments.go from:
case utils.MatchContentType(httpRes.Header.Get("Content-Type"), `application/json; charset=UTF-8`):To:
case utils.MatchContentType(httpRes.Header.Get("Content-Type"), `application/json`):This will accept application/json with or without charset parameters, which is the correct behavior according to HTTP standards
Additional Notes
- This bug was discovered during migration from the deprecated
Statusendpoint to theDebugendpoint - The deprecated
Statusendpoint did not have this issue - The bug affects production systems that rely on the Debug endpoint for health checks and monitoring
Version Information
- Tested versions: v0.11.29, v0.11.30 (both affected)
- Discovery date: 2026-03-12 during migration from deprecated
Statusendpoint
This bug exists in the Debug endpoint implementation across multiple SDK versions. The deprecated Status endpoint works correctly, suggesting the issue is specific to the Debug endpoint's response parsing logic.