[konlue]

Fixes #7731.

Summary

InstanceInfoVO has no id property and InstanceInfoServiceImpl#buildInstanceInfoVO copies all persisted fields except the primary key. Both the instance list and detail endpoints use that conversion, so the dashboard's item.key = item.id receives an undefined value and table row selection has no stable key.

Modifications

• Add the id field (with getter/setter) to InstanceInfoVO.
• Copy the DO id in the shared DO-to-VO conversion, which covers list, detail and paging responses.
• Add regression coverage for the response contract.

Verifying this change

• New InstanceInfoServiceImplTest: findById propagates the record id; listByPage exposes distinct non-empty ids for two records.

• InstanceControllerTest: asserts dataList[0].id / dataList[1].id in the list JSON and data.id in the detail JSON.

• Red-green: removing the conversion line makes the service tests fail with a null id; restoring it passes (service 2/2, controller 4/4).

• Targeted tests pass:

  ./mvnw -B -ntp -pl shenyu-admin test -Dtest=InstanceInfoServiceImplTest,InstanceControllerTest

  6/6 green.

• Checkstyle passes:

  ./mvnw -B -ntp -pl shenyu-admin checkstyle:check

  clean.

Notes

The dashboard already keys instance rows by item.id, so this backend change is sufficient; no dashboard change is included. Live heartbeat-map overlays in the controller only replace heartbeat time/state/update time, leaving the persisted id intact.

[Aias00]

LGTM. The VO really had no id, and the DO→VO conversion is the single chokepoint for list, detail and paging, so one line fixes all three surfaces.

Evidence

• InstanceInfoVO previously exposed ip/port/type/info/namespaceId/state/dates/heartbeat and nothing else; buildInstanceInfoVO copied every persisted field except the key. The dashboard keying rows by item.id therefore received undefined, as reported.
• createOrUpdate builds its lookup from ip/port/type/namespace and its updateById from the DO it fetched, so adding id to the VO changes nothing on the write path.
• The controller overlay in queryPlugins only replaces heartbeat time/state/updated time, so the persisted id survives the enrich step, as the PR body says.
• The tests assert both the JSON contract (dataList[0].id, data.id) and distinctness of two records, which is the property the dashboard actually needs.

Cross-PR note (please act on it)

#7749 (already approved) adds a manual copyInstanceInfoVO in InstanceCheckService that enumerates all nine VO fields — it predates this field. After both merge that copy will leave id null. It is harmless today because createOrUpdate never reads the VO id, but if #7749 lands second, please add copy.setId(vo.getId()) there so the "complete copy" invariant stays true.

Nit: serialVersionUID stays unchanged although the class gained a field — fine for a VO that is never deserialized from a stream, just noting it in case anyone expects strict compatibility.

[konlue]

Thanks for the cross-PR catch. On serialVersionUID : leaving it unchanged intentionally — the VO never round-trips through Java serialization. On #7749: I've left a note on that PR so its author knows copyInstanceInfoVO will need copy.setId(vo.getId()) once this PR merges (the field doesn't exist on their branch yet, so it can't go in before). If it merges without the line, I'll follow up with the one-liner myself.