Tencent/WeKnora · warning

wiki graph request is required

Error message

wiki graph request is required

What it means

GetGraph requires a WikiGraphRequest; when the request pointer is nil the service returns this error. Building the wiki graph needs the KnowledgeBaseID (and filter/top-N settings) from the request, so a nil request is unusable. This is a defensive nil-check before any repository work.

Source

Thrown at internal/application/service/wiki_page.go:578

//     node in the overview.
//
// `Types` is an optional page_type allow-list applied to both the candidate
// node set and (in ego mode) the frontier expansion. Leaving it empty means
// no type filter.
//
// `Limit <= 0` disables the cap entirely and is reserved for internal
// callers like the lint service that need to walk every page. The HTTP
// handler always clamps Limit into a safe range so external traffic can
// never opt out of truncation.
//
// Implementation note: pages are still fetched via repo.ListAll. At 4万
// pages that's ~10MB of rows + deserialization, which is already on the
// expensive side but still tractable and keeps the repository interface
// unchanged. Pushing the filter/top-N down into SQL is a follow-up step
// (cache layer + DB-side projection) — see CLAUDE.md plan.
func (s *wikiPageService) GetGraph(ctx context.Context, req *types.WikiGraphRequest) (*types.WikiGraphData, error) {
	if req == nil {
		return nil, errors.New("wiki graph request is required")
	}

	pages, err := s.repo.ListAll(ctx, req.KnowledgeBaseID)
	if err != nil {
		return nil, err
	}
	return computeGraphSubset(pages, req)
}

// computeGraphSubset is the pure I/O-free core of GetGraph. It takes the
// full page list and a request description and returns the subgraph the
// caller asked for. Extracted from GetGraph so tests can exercise the
// mode/limit/type-filter behavior without plumbing a full repository mock.
func computeGraphSubset(pages []*types.WikiPage, req *types.WikiGraphRequest) (*types.WikiGraphData, error) {
	mode := req.Mode
	if mode == "" {
		mode = types.WikiGraphModeOverview
	}

View on GitHub (pinned to 988cbb0330)

Solutions

1. Always construct and pass a WikiGraphRequest (at minimum with KnowledgeBaseID) to GetGraph.
2. Fix the handler to return 400 on body decode failure instead of passing a nil request.
3. Add a nil check at the caller level before invoking the service.

Example fix

// before
var req *types.WikiGraphRequest
if err := c.ShouldBindJSON(&req); err != nil { /* ignored */ }
data, err := h.svc.GetGraph(ctx, req)
// after
var req types.WikiGraphRequest
if err := c.ShouldBindJSON(&req); err != nil {
    return httpError(400, "invalid request")
}
data, err := h.svc.GetGraph(ctx, &req)

if req == nil {
    return httpError(400, "wiki graph request is required")
}

func validGraphRequest(r *types.WikiGraphRequest) bool {
    return r != nil && strings.TrimSpace(r.KnowledgeBaseID) != ""
}

When it happens

Trigger: Calling GetGraph(ctx, nil) — e.g. a handler that failed to decode/bind the request body but continued, or internal callers constructing the request conditionally.

Common situations: Handler skips JSON body decoding error handling and passes a nil struct; internal code paths building requests dynamically that end up unset; tests invoking the service without a request object.

Related errors

• favorite resource id is required
• enqueue wiki ingest trigger: task enqueuer is nil
• wiki page slug is required
• knowledge_base_id is required
• cannot revert to the current version

AI-assisted analysis of Tencent/WeKnora@988cbb0330 (2026-09-02). Data as JSON: /api/errors/2f7e7578e777844e. Report an issue: GitHub.