The trace function does not work after upgrading skywalking-horizon-ui to the latest version, 0.7.0.

[Hwting]

Hi, has anyone else encountered this situation? Also, I haven't found any relevant error logs.

oap-server:10.4.0
horizon-0.7.0

1.Version 0.6.0 is working correctly：

2.racing is not working in version 0.7.0：

3.According to the documentation, it is compatible：
https://skywalking.apache.org/docs/skywalking-horizon-ui/latest/compatibility/oap-version/

[wu-sheng]

You could try the latest code(dev version). We have fixed a lot since 0.7.
Also, I saw you don't have the v2 query API banner, so, maybe that is v1-query bug. I remember there was one.

[Hwting]

Thanks for the reply; I’ve compared the code between v0.6.0 and main.
The root cause is that the trace route was changed from using the bundled getLayerTemplate('general') (as in v0.6.0) to resolveEffectiveLayer. When the OAP Admin UI template endpoint is unreachable (e.g., the oapv10.4 admin service is unavailable), client.list() throws an error, setting sync.unreachable = true and eff.blocked = true. Consequently, the route returns only { generatedAt, source } without the native or zipkin fields, resulting in an empty UI display. In contrast, v0.6.0 uses a bundled template and does not depend on the OAP admin server. While the observed behavior is as expected, the Topology view might be facing the same issue. Should this be addressed?

[wu-sheng]

Thanks for the root-cause analysis — it is exactly right, and it saved us the diagnosis.

Confirming the mechanism from the Horizon side. In 0.7.0 layer resolution moved to the OAP-stored template set, and when that store cannot be read Horizon treated it as a deliberate block: routes served nothing rather than render a layer definition it could not verify. On OAP 10.x the store can never be read, because /ui-management/templates* is an OAP 11 module — template management on 10.x lives on the query port's GraphQL (getTemplate / getAllTemplates / addTemplate / changeTemplate / disableTemplate, writes gated by SW_ENABLE_UPDATE_UI_TEMPLATE), and Horizon implements only the OAP 11 REST protocol. So the block was permanent, and Traces — which resolves its query fields from the layer template — came back empty. 0.6.0 was unaffected because it read the bundled template directly, as you found.

The block was the wrong trade. A blank page is not safer than a stated fallback, and this case is predictable rather than exotic. Fix is up in apache/skywalking-horizon-ui#103: when the template store is unreachable, Horizon now renders the layer templates bundled in the release, and the connectivity banner keeps reporting the store as unreachable so the degrade is visible instead of silent. An admin-disabled layer still blocks, since that is a different and deliberate signal.

Tip

Workaround on 0.7.0 today — set templates.mode: readonly (env HORIZON_TEMPLATES_MODE=readonly).

templates:
  mode: readonly

Horizon then renders every dashboard from the bundle and never contacts the template store — effectively the 0.6.0 behavior. This remains the recommended setting on an OAP 10.x even after the fix, because it states the deployment's reality up front and makes the admin pages honestly display-only rather than offering saves that cannot land.

The one thing a bundled fallback cannot give you is a template edit stored on OAP; on 10.x that is moot, since Horizon cannot read or write that store there anyway.

Two other 10.x limits worth knowing, both from Horizon's current queries rather than from OAP: queryTrace(..., duration) first appears in OAP 10.3, and findEndpoint(..., duration) in 10.2. On earlier 10.x minors those calls fail on an unknown argument, so native trace detail wants 10.3+.