What causes "{entity} 不存在: {parameter} is {value}" in elunez/eladmin?

Verify the id actually exists (GET the list endpoint or query the table) and correct the client.

elunez/eladmin · error · BadRequestException

{entity} 不存在: {parameter} is {value}

Error message

{entity} 不存在: {parameter} is {value}

What it means

ValidationUtil.isNull is a generic existence guard: when the looked-up object is null it throws BadRequestException with a message of the form '<entity> 不存在: <parameter> is <value>'. Service layers (e.g. AppServiceImpl.findById, many modules) call it right after repository.findById(...).orElseGet(X::new) to convert an empty lookup into a 400 response.

Source

Thrown at eladmin-common/src/main/java/me/zhengjie/utils/ValidationUtil.java:36

import cn.hutool.core.lang.Validator;
import cn.hutool.core.util.ObjectUtil;
import me.zhengjie.exception.BadRequestException;

/**
 * 验证工具
 *
 * @author Zheng Jie
 * @date 2018-11-23
 */
public class ValidationUtil {

    /**
     * 验证空
     */
    public static void isNull(Object obj, String entity, String parameter , Object value){
        if(ObjectUtil.isNull(obj)){
            String msg = entity + " 不存在: "+ parameter +" is "+ value;
            throw new BadRequestException(msg);
        }
    }

  /**
   * 验证是否为邮箱
   */
  public static boolean isEmail(String email) {
    return Validator.isEmail(email);
  }
}

View on GitHub (pinned to 55fbf70595)

Solutions

Verify the id actually exists (GET the list endpoint or query the table) and correct the client.
If the record was deleted, refresh the frontend list/cache so stale ids are not reused.
Check you are pointing at the right database/environment for the id you hold.
For creators of APIs: return 404 semantics or a localized message instead of leaking 'is null' style details.

Example fix

// before
App app = appRepository.findById(id).orElseGet(App::new);
ValidationUtil.isNull(app.getId(), "App", "id", id);

// after: fail with a clear 404-style message
App app = appRepository.findById(id)
        .orElseThrow(() -> new BadRequestException("App 不存在: id is " + id));

Defensive patterns

Strategy: validation

Validate before calling

// Caller: verify existence before acting on an id
boolean exists = appRepository.existsById(id);
if (!exists) {
    return notFound("App id=" + id); // avoid invoking downstream logic
}
AppDto dto = appService.findById(id);

Type guard

private boolean isExistingId(Long id) {
    return id != null && id > 0 && appRepository.existsById(id);
}

Try / catch

try {
    return service.findById(id);
} catch (BadRequestException e) {
    if (e.getMessage().contains("不存在")) return ResponseEntity.notFound().build();
    throw e;
}

Prevention

Refresh lists/caches after deletions so stale ids are never submitted.
Use existsById() or orElseThrow with a domain-specific message instead of orElseGet + isNull for clearer failures.
Validate id format and range at the controller boundary.
Confirm you are querying the same environment/database your ids came from.

When it happens

Trigger: Any GET /api/xxx/{id} (or update/delete) where the entity with that id does not exist in the database — e.g. requesting App with id=99 after orElseGet(App::new) leaves id null. Also stale frontend state holding an id deleted by another user or after a re-seeded database.

Common situations: Deleted or never-created records still referenced by the frontend; wrong environment (querying dev data from a prod-configured client); id type mismatch (passing a String where Long is expected causing a lookup miss); concurrent deletion between list and detail views.

Related errors

AI-assisted analysis of elunez/eladmin@55fbf70595 (2026-08-14). Data as JSON: /api/errors/e6e333e1c05e15d8. Report an issue: GitHub.