Go SDK panic on 504 and 204 status codes

[dbblackdiamond]

Hi,

I am new to Weaviate and have built a program to ingest documents into Weaviate using the Go SDK. I am running Weaviate v1.34.0 deployed on GKE and using Go client v4.16.1.
I was doing some testing today and at one point, tried to ingest some documents while the Weaviate cluster was being reconfigured and the cluster threw a 504 or 204 status codes, which lead to a panic in the Go client. Here is the output:

2025-12-04T14:19:54.752-0700	INFO	weaviate/client.go:146	putting document	{"component": "weaviate_client", "doc_id": "10043379", "class_name": "wikipedia"}


2025/12/04 14:19:54 [Recovery] 2025/12/04 - 14:19:54 panic recovered:
POST /index/batch HTTP/1.1
Host: localhost:8088
Accept-Encoding: gzip
Content-Length: 1062192
Content-Type: application/json
User-Agent: Go-http-client/1.1


runtime error: invalid memory address or nil pointer dereference
/opt/homebrew/Cellar/go/1.25.2/libexec/src/runtime/panic.go:262 (0x1042c2e17)
	panicmem: panic(memoryError)
/opt/homebrew/Cellar/go/1.25.2/libexec/src/runtime/signal_unix.go:925 (0x1042c2de8)
	sigpanic: panicmem()
/Users/bertrandsirodot/go/pkg/mod/github.com/weaviate/weaviate-go-client/v4@v4.16.1/weaviate/data/checker.go:44 (0x10495602c)
	(*Checker).Do: exists := responseData.StatusCode == 204
/Users/bertrandsirodot/Documents/source/retrieval_v2/internal/adapters/outbound/weaviate/client.go:655 (0x10496dcef)
	(*Client).documentExists: Do(ctx)
/Users/bertrandsirodot/Documents/source/retrieval_v2/internal/adapters/outbound/weaviate/client.go:155 (0x10496a30f)
	(*Client).PutDocument: exists, err := c.documentExists(ctx, docID)
/Users/bertrandsirodot/Documents/source/retrieval_v2/internal/adapters/outbound/weaviate/repository.go:157 (0x1049718cf)
	(*HybridRepository).Store: err := r.client.PutDocument(ctx, doc.ID, doc)
/Users/bertrandsirodot/Documents/source/retrieval_v2/internal/domain/usecases/hybrid_search_usecase.go:141 (0x104739463)
	(*HybridSearchUseCase).IndexDocument: if err := uc.hybridRepo.Store(ctx, doc); err != nil {
/Users/bertrandsirodot/Documents/source/retrieval_v2/internal/adapters/inbound/http/hybrid_ingestion_handler.go:324 (0x10473c6fb)
	(*HybridIngestionHandler).BatchIndex: if err := h.useCase.IndexDocument(c.Request.Context(), doc); err != nil {
/Users/bertrandsirodot/go/pkg/mod/github.com/gin-gonic/gin@v1.9.1/context.go:174 (0x1046f6ce7)
	(*Context).Next: c.handlers[c.index](c)
/Users/bertrandsirodot/Documents/source/retrieval_v2/internal/infrastructure/logging/middleware.go:99 (0x10497e18b)
	main.RequestIDMiddleware.func9: c.Next()
/Users/bertrandsirodot/go/pkg/mod/github.com/gin-gonic/gin@v1.9.1/context.go:174 (0x1046f6ce7)
	(*Context).Next: c.handlers[c.index](c)
/Users/bertrandsirodot/Documents/source/retrieval_v2/internal/infrastructure/logging/middleware.go:29 (0x10497d777)
	main.GinMiddleware.func8: c.Next()
/Users/bertrandsirodot/go/pkg/mod/github.com/gin-gonic/gin@v1.9.1/context.go:174 (0x1047015d7)
	(*Context).Next: c.handlers[c.index](c)
/Users/bertrandsirodot/go/pkg/mod/github.com/gin-gonic/gin@v1.9.1/recovery.go:102 (0x1047015c0)
	CustomRecoveryWithWriter.func1: c.Next()
/Users/bertrandsirodot/go/pkg/mod/github.com/gin-gonic/gin@v1.9.1/context.go:174 (0x10470063b)
	(*Context).Next: c.handlers[c.index](c)
/Users/bertrandsirodot/go/pkg/mod/github.com/gin-gonic/gin@v1.9.1/gin.go:620 (0x1047003a4)
	(*Engine).handleHTTPRequest: c.Next()
/Users/bertrandsirodot/go/pkg/mod/github.com/gin-gonic/gin@v1.9.1/gin.go:576 (0x104700023)
	(*Engine).ServeHTTP: engine.handleHTTPRequest(c)
/opt/homebrew/Cellar/go/1.25.2/libexec/src/net/http/server.go:3340 (0x10450f03f)
	serverHandler.ServeHTTP: handler.ServeHTTP(rw, req)
/opt/homebrew/Cellar/go/1.25.2/libexec/src/net/http/server.go:2109 (0x1044f1197)
	(*conn).serve: serverHandler{c.server}.ServeHTTP(w, w.req)
/opt/homebrew/Cellar/go/1.25.2/libexec/src/runtime/asm_arm64.s:1268 (0x1042c8bf3)
	goexit: MOVD	R0, R0	// NOP

This issue seems to be in the checker.go file where it is not able to handle the 504 status code. Let me know if you need any additional information to resolve this bug.

Thanks a lot,
Bertrand.