weaviate / weaviate/java-client

v6: groups/UserType spells db_env_user as db_end_user, and is an unreferenced duplicate

Open
#623 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Java
Stars
34
Forks
30
PR merge metrics
No merged PRs in 30d

Description

Summary

rbac/groups/UserType spells one of its wire values db_end_user. The server's value is db_env_userenv, not end. So DB_ENV_USER can never be produced by a read, and writing it would emit a value the server rejects.

It is also unreferenced, which is almost certainly why the typo survived: nothing in src/main, src/test or src/it uses this enum. That makes it a latent defect rather than a live one, and it may be that the right fix is deletion rather than a correction — see below.

Where it comes from

io/weaviate/client6/v1/api/rbac/groups/UserType.java (6.3.1) — the whole file:

public enum UserType {
  @SerializedName("db_user")
  DB_USER,
  @SerializedName("db_end_user")   // <-- server value is db_env_user
  DB_ENV_USER,
  @SerializedName("oidc")
  OIDC
}

The server's enumeration, entities/models/d_b_user_info.go:142:

if err := json.Unmarshal([]byte(`["db_user","db_env_user"]`), &res); err != nil {

The constant is named DB_ENV_USER, so the intent was clearly db_env_user; only the string is wrong.

It is a duplicate, not the live one

There are two public UserType enums in sibling packages:

used by db_env_user
rbac/users/UserType UserAssignment, GetAssignedRolesRequest, DbUsersClient, NamespacedUsersClient, RbacITest via @SerializedName(value = "db", alternate = "db_env_user")
rbac/groups/UserType nothing db_end_user — wrong

grep -rn "UserType" src/ returns the users copy everywhere and the groups copy nowhere. (GroupType, in the same package, is used — this is not a case of the whole package being dead.)

Suggested fix

Two options, and I do not want to presume which you want:

  1. Delete rbac/groups/UserType. It is an unreferenced duplicate of a type that already exists and already handles this value correctly. The typo is evidence that nothing has ever exercised it. This removes a trap for whoever wires up the groups client next — they would reach for the enum in their own package and get the broken one. It is a public type, so removing it is a breaking change on paper, even though nothing inside the client can be broken by it.

  2. Correct the string to db_env_user. Safe and non-breaking, but leaves two divergent copies of the same concept in the tree, which is how this happened.

The attached PR does (2), as the lower-risk default. Say the word and I will switch it to (1).

Version

  • java-client 6.3.1
  • Weaviate 1.39.0

Contributor guide

No contributing guide indexed for this repository

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 with io/weaviate/client6/v1/api/rbac/groups/UserType.java and compare it with rbac/users/UserType. Use the reported grep across src/ to verify whether the groups enum is referenced, then confirm the selected correction or deletion matches the public API and the server value db_env_user. Done means the duplicate and wire-value behavior are resolved consistently.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
api, authorization
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.