weaviate / weaviate/java-client
v6: groups/UserType spells db_env_user as db_end_user, and is an unreferenced duplicate
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_user — env, 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:
-
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. -
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
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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