Is data obtained via graphql limited to 100 buckets by design?

[mike-realuptime]

Hi! I have been working with my own library on top of skywalking's oap graphql's queries. depending on resolution and interval requested, several tests shown that only 100 buckets max are returned. This is true and visible even on new horizon's UI (ask for last 4 hours only get first 100 minutes) - Is that by design or is it a bug? I will appreciate if somebody can help me understand this. Regards. - Miguel

[wu-sheng]

There is a limit, but it isn't 100, and what you hit is not by design — it's a bug. Thanks for the clear report.

The intended limit is 500 points, and it errors instead of truncating. DurationUtils.MAX_TIME_RANGE = 500 is the only cap the query layer means to impose, and exceeding it raises Duration data error, the range between the start time and the end time can't exceed 500 minutes. Your 4-hour minute-step query is 240 points — well inside that — so it should have come back in full.

The 100 comes from the storage engine, not from SkyWalking's query layer. BanyanDB applies its own default limit to any query that arrives without one — 100 rows for measures (defaultLimit in pkg/query/logical/measure/measure_analyzer.go), 20 for streams/traces — and it applies that default after any GROUP BY, so the result set is silently shortened rather than rejected. OAP was building the metrics read as WHERE entity_id = ? with no LIMIT at all, so the server filled in 100. The remaining 140 points then fell into the "no data for this bucket" branch and rendered as empty, which is exactly the "first 100 minutes only" symptom you and the Horizon UI are seeing.

So: step and the time range were being honoured; the row cap was being supplied by BanyanDB behind OAP's back.

This is BanyanDB-only. Elasticsearch fetches those rows by explicit document id (MetricsQueryEsDAO) and JDBC uses id IN (...), so neither has ever had a cap on this path. If you can switch storage, that sidesteps it entirely.

Fix: #13961. Every BydbQL query now leaves OAP carrying an explicit LIMIT — the entity-scoped metrics read sends the exact number of assembled duration points, so the only remaining ceiling is the 500-step gate above. The same latent cap was also shortening topology relation maps, instance and process metadata lists, profiling thread snapshots and eBPF task lists; those are fixed in the same PR.

Until that ships, a query whose point count stays at or under 100 returns complete data — so a coarser step (HOUR for a 4-hour window), or splitting a long range into sub-100-point requests, both work around it.

[mike-realuptime]

It looked like a bug :) Thank you for your kind answer! best regards

[wu-sheng]

Yes, it is. But truly, the cap exists as well.