[konlue]

Fixes #7696.

Summary

The independent heartbeat channel reports InstanceTypeConstants.BOOTSTRAP_INSTANCE_INFO as the instance type. That constant is the payload key ("bootstrapInstanceInfo") used by the WebSocket map and the HTTP sync header; the actual type is BOOTSTRAP_INSTANCE_TYPE ("bootstrap"), which the WebSocket collector and the HTTP long-polling listener already report.

Because the admin instance identity includes the type and queries filter on instance_type, the same bootstrap ends up with a second, invisible identity.

Modifications

• Use BOOTSTRAP_INSTANCE_TYPE when building the periodic heartbeat payload in HeartbeatListener.
• Add a regression test that runs the scheduled task, captures the JSON payload passed to RegisterUtils.doHeartBeat, deserialises it, and asserts the reported instanceType.

Verifying this change

• Red-green: with the original constant restored, the new test fails with expected: <bootstrap> but was: <bootstrapInstanceInfo>; with the fix, it passes.

• Targeted tests pass:

  ./mvnw -B -ntp -pl shenyu-register-center/shenyu-register-client-beat test -Dtest=HeartbeatListenerTest

  10/10 green.

• Checkstyle passes:

  ./mvnw -B -ntp -pl shenyu-register-center/shenyu-register-client-beat checkstyle:check

  clean.

Notes

No migration for already persisted bootstrapInstanceInfo rows: this change makes subsequent reports consistent with the other sync channels; normalising historical rows (if desired) is a separate operational decision. The payload key constants are untouched — only the instanceType value changes.

Upgrade note (review follow-up)

Rows persisted with the old bootstrapInstanceInfo instance type age out through the normal offline→deleted cycle; since the instance list is not filtered by state, dashboards show a phantom deleted row per bootstrap until those rows are cleaned up. Prefer deleting the stale rows and letting the corrected heartbeat re-register over an in-place UPDATE — updating the type in place can collide with a row already created by the corrected channel.

[Aias00]

LGTM. The constants really do differ in meaning, and this makes the beat channel agree with the other two.

Evidence

• InstanceTypeConstants has BOOTSTRAP_INSTANCE_INFO = "bootstrapInstanceInfo" (the payload key read from the WebSocket map and the HTTP sync header) and BOOTSTRAP_INSTANCE_TYPE = "bootstrap" (the instance type). Confirmed both in shenyu-common.
• WebsocketCollector:206 and HttpLongPollingDataChangedListener both report BOOTSTRAP_INSTANCE_TYPE, so the beat channel was the only producer using the payload-key constant. Since InstanceCheckService keys live entries as ip:port@type#namespace and InstanceController filters on instance_type, that mismatch really did create a second identity per bootstrap.
• The test captures the JSON payload actually handed to RegisterUtils.doHeartBeat and deserialises it, which is the only assertion that proves the wire value rather than the constant reference — good instinct, since the bug was precisely a wrong constant.

Upgrade note (please add it to the PR body)

Existing deployments already have rows with instance_type = 'bootstrapInstanceInfo'. After this change those rows stop being refreshed, so InstanceCheckService ages them to OFFLINE and then DELETED, and syncDB persists that — but instance_info.selectByQuery does not filter by state, so the dashboard will keep showing one phantom DELETED row per bootstrap. A short release note with the cleanup statement would save operators a confusing ticket. If you suggest an UPDATE, mention that it can collide with a freshly created bootstrap row for the same ip/port/namespace, so a delete-and-let-it-reregister is the safer recipe.

CI: pr_build green. The red build (shenyu-integrated-test-k8s-gateway-api-http) job died with DaemonException$StaleAddressException (mvnd daemon), i.e. infrastructure, not this change.

[konlue]

Done. Upgrade note added to the PR body — it documents that rows with the old bootstrapInstanceInfo type age out into a phantom deleted row (the list isn't filtered by state) and recommends delete-and-reregister over an in-place UPDATE, per your review.