Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Bug] Trace profiling segment list becomes empty after the task finishes, while still inside the query window

Aperta
  • Qualcosa non va?
#14,172 3 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@hanahmily ci sta già lavorando.

Dal 27/10/2026.

  • #1444 di @hanahmily — aperta

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

bug database
Search before asking
  • I had searched in the issues and found no similar issues.
Apache SkyWalking Component

OAP server (apache/skywalking)

What happened

GET /api/profile/tasks/{taskId}/segments (Horizon proxy of GraphQL getProfileTaskSegments) was called twice for one task. Both responses were HTTP 200. The task id was identical, including the millisecond prefix. The service id is redacted as {serviceId}.

  • Task id: 1793082425169_{serviceId}
  • Duration: 5 minutes
request Date (GMT) Content-Length body
1 Tue, 27 Oct 2026 06:29:50 GMT 300605 4 profiled segments, reachable: true
2 Tue, 27 Oct 2026 06:32:36 GMT 32 {"segments":[],"reachable":true}

Content-Length: 32 is {"segments":[],"reachable":true}. The 4 segments on request 1 start 87.7-114.5 s after the task-id prefix, with durations 48-217 ms. Each has a profiled entry span.

Environment:

  • OAP apache/skywalking-oap-server:11.0.0, BanyanDB apache/skywalking-banyandb:0.11.0 standalone, UI apache/skywalking-ui:horizon-1.0.0
  • OAP and BanyanDB use TZ=Asia/Shanghai. SW_STORAGE=banyandb, target banyandb:17912
  • No bydb.yml, TTL, trace-pipeline, or Kafka exporter overrides. Image defaults apply: trace and records TTL are 3 days

Request 1 shows these 4 segments had been written.

The prefix 1793082425169 is 2026-10-27T06:27:05.169Z. Collection ends at 2026-10-27T06:32:05.169Z. The response Date headers sit on that timeline.

v11.0.0 ProfileTaskQueryService.getTaskSegments queries [end - 10 min, end + 15 min]:

long endTimestamp = profileTask.getStartTime() + (long) profileTask.getDuration() * 60 * 1000;
DateTime endTime = new DateTime(endTimestamp + 15 * 60 * 1000);
DateTime startTime = new DateTime(endTimestamp - 10 * 60 * 1000);

With startTime equal to that prefix, the window is [2026-10-27T06:22:05.169Z, 2026-10-27T06:47:05.169Z].

  • Request 1 at 06:29:50Z is 135 s before collection end.
  • Request 2 at 06:32:36Z is 31 s after collection end, and about 14 min 29 s before the window closes.

getProfileTaskSegments returns empty as soon as getTaskSegments is empty. getTaskSegments loads the task with getById first, so this HTTP 200 means the task record was still present. The payload does not show which stage dropped the rows: queryRecords(taskId), queryBySegmentIdList, or the later rebuild by trace id.

What you expected to happen

The same task still returns those 4 segments while the request is inside [end - 10 min, end + 15 min].

How to reproduce
  1. Create one 5-minute trace profiling task.
  2. Call getProfileTaskSegments during the window.
  3. Call the same task id again after collection end and before end + 15 min.

Observed: 06:29:50Z returned 4 segments; 06:32:36Z returned an empty list, 31 s after collection end.

Anything else
  • The data keeper runs every 5 minutes. The default 3-day trace and record TTL does not expire data written about 10 minutes earlier.
  • #13534 and #13961 are already in 11.0.0. #13961 stops silent caps at 20 or 100 rows. This list had 4 rows, then became empty.
  • The four traces were not opened again on the Trace page after the list became empty.
  • Horizon is only the caller. The empty list comes from the OAP query against BanyanDB.
Are you willing to submit a pull request to fix on your own?
  • Yes I am willing to submit a pull request on my own!
Code of Conduct
Lingua principale
Java
Stelle
25k
Fork
6.6k
Merge medio
15h 4m
PR unite (30g)
32

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di apache/skywalking

Tutte le issue di apache/skywalking

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.