gleanwork / gleanwork/api-client-go

Debug endpoint returns an error despite successful API call

Open
#84 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Go
Stars
5
Forks
1
Avg merge
1d 6h
Merged PRs (30d)
17

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-go v0.11.30 (also affects v0.11.29)
  • Endpoint: POST /api/index/v1/debug/{datasource}/document
  • Note: The deprecated Status endpoint (/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:

  1. Parse the response successfully
  2. Return the parsed response object
  3. Return nil error

Actual Behavior

The SDK:

  1. Makes a successful API call (HTTP 200)
  2. Returns an error: unknown content-type received: application/json: Status 200\n{...json response...}
  3. Returns nil for 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:

  1. test-debug-endpoint.go - Uses the SDK, demonstrates the bug
  2. 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 MatchContentType function uses mime.ParseMediaType which should handle this correctly
  • However, the pattern application/json; charset=UTF-8 doesn't match application/json
  • When the match fails, it falls through to the default case 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 Status endpoint to the Debug endpoint
  • The deprecated Status endpoint 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 Status endpoint

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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in indexingdocuments.go around line 1226 and inspect the Debug response handling and utils.MatchContentType behavior. Reproduce the response using the provided SDK or raw HTTP examples, then run the relevant existing tests if available; done means a 200 response with Content-Type application/json is parsed into the response object and returns a nil error.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
api, backend
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Stale
Clarity
Clearly specified
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.