[0.26.0] Empty partition causes loading data indefinitely

[kbarczynski-rtbh]

If the partition is empty (no records) data-loading process looks like never-ending.
Pre-loader icon is displayed, no error-message is shown (just an empty black-box in the top-right corner):

When I change partition from empty partition:

• https://akhq.{host}/ui/central-dkafka/topic/url***_configs/data?sort=Oldest&partition=2

to not-empty partition:

• https://akhq.{host}/ui/central-dkafka/topic/url***_configs/data?sort=Oldest&partition=10

it works fine:

partition=All does not work as well.

[AlexisSouquiere]

@krisso-rtb what is the value of

akhq:
  topic-data:
    poll-timeout: 1000

This behaviour can happen because we are waiting the timeout value on empty partitions before returning data for the topic.
This poll-timeout should be small enough to avoid this kind of latency

[kbarczynski-rtbh]

@krisso-rtb what is the value of

akhq:
topic-data:
poll-timeout: 1000
This behaviour can happen because we are waiting the timeout value on empty partitions before returning data for the topic. This poll-timeout should be small enough to avoid this kind of latency

@AlexisSouquiere I tried with different values of poll-timeout and the issue still exists.
What's more - it exists on topics with all partitions having tons of events.

[AlexisSouquiere]

Please paste your application.yml to see the actual configuration you are using. I experienced this issue on my side when someone increased the timeout

[kbarczynski-rtbh]

Please paste your application.yml to see the actual configuration you are using. I experienced this issue on my side when someone increased the timeout

micronaut:
  server:
    port: 9090
    cors:
      enabled: true
  security:
    enabled: true
    ...
    token:
      jwt:
        ...
akhq:
  security:
    ...
  topic-data:
    poll-timeout: 30000
  clients-defaults:
    consumer:
      properties:
        default.api.timeout.ms: 60000
  connections:
  ...

I tried with various values of poll-timeout: 30000 and the issue still exists.
What's more - the issue does not exist if I rollback to version 0.24.0 (without any changes in application.yml)