fix(top): handle UI events separately to prevent UI freeze

[esensar]

Summary

Transition to gRPC for API introduced a higher number of events, causing high load in state updater when many components are present, blocking the UI events from being sent to the channel (because it gets full fast). This introduces a separate channel for UI events to ensure they get a chance to be processed.

Vector configuration

Configuration with a high number of components (from #24355):

api:
  enabled: true

sources:
  demo_logs_test:
    type: "demo_logs"
    format: "json"

  demo_logs_test2:
    type: "demo_logs"
    format: "json"
  demo_logs_test3:
    type: "demo_logs"
    format: "json"
  # ... repeat many times

transforms:
  demo_logs_processor:
    type: "remap"
    inputs: ["demo_logs_test"]
    source: |
      . = parse_json!(.message)

  demo_logs_processor2:
    type: "remap"
    inputs: ["demo_logs_test2"]
    source: |
      . = parse_json!(.message)
  # ... repeat many times
  
sinks:
  console:
    inputs: ["demo_logs_processor"]
    target: "stdout"
    type: "console"
    encoding:
      codec: "json"

  console2:
    inputs: ["demo_logs_processor2"]
    target: "stdout"
    type: "console"
    encoding:
      codec: "json"
  
  # ... repeat many times

How did you test this PR?

Ran vector with the above configuration and ran vector top separately. Without this patch, pressing ? or any other keybind (other than q) would freeze top completely. After this patch the UI event gets processed as expected.

Change Type

• Bug fix
• New feature
• Dependencies
• Non-functional (chore, refactoring, docs)
• Performance

Is this a breaking change?

• Yes
• No

Does this PR include user facing changes?

• Yes. Please add a changelog fragment based on our guidelines.
• No. A maintainer will apply the no-changelog label to this PR.

References

• Related: feat(cli): add scrolling, sorting and filtering to vector top #24355
• Related: chore(api)!: replace GraphQL observability API with gRPC, remove async-graphql dependencies #24364

Notes

• Please read our Vector contributor resources.
• Do not hesitate to use @vectordotdev/vector to reach out to us regarding this PR.
• Some CI checks run only after we manually approve them.
  • We recommend adding a pre-push hook, please see this template.
  • Alternatively, we recommend running the following locally before pushing to the remote branch:
    • make fmt
    • make check-clippy (if there are failures it's possible some of them can be fixed with make clippy-fix)
    • make test
• After a review is requested, please avoid force pushes to help us review incrementally.
  • Feel free to push as many commits as you want. They will be squashed into one before merging.
  • For example, you can run git merge origin master and git push.
• If this PR introduces changes Vector dependencies (modifies Cargo.lock), please
  run make build-licenses to regenerate the license inventory and commit the changes (if any). More details on the dd-rust-license-tool.

---

Sponsored by Quad9

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8478de4d84

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4dba39cc8c

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[pront]

Hi @esensar, thank you for this fix. This made me think a bit more about the top dashboard design. We always want to render the latest state, but we are unnecessarily rendering all snapshots in order (received via a bounded FIFO mpsc channel).

Example:

We are queuing states: [A,B,C,D]

We render: state A -> state B -> state C -> state D

But we only need to render state D.

Does the above make sense?

We can probably fix this by using a watch::channel, so metric updates can coalesce and the renderer always observes the freshest state.

[esensar]

Hi @esensar, thank you for this fix. This made me think a bit more about the top dashboard design. We always want to render the latest state, but we are unnecessarily rendering all snapshots in order (received via a bounded FIFO mpsc channel).

Example:

We are queuing states: [A,B,C,D]

We render: state A -> state B -> state C -> state D

But we only need to render state D.

Does the above make sense?

Yes, it makes sense. I noticed that too while working on this, but I wanted to limit the scope of the fix, so I handled it on UI side.

We can probably fix this by using a watch::channel, so metric updates can coalesce and the renderer always observes the freshest state.

That makes sense - I did that myself, but using watch::channel should be much simpler.

[esensar]

I have changed it to use watch::channel and removed the state coalescing from dashboard code. UI updates are now triggered with each state update now, instead of 60 times per second, but it should always show the latest state. The actual updates that come from gRPC might still be delayed, because processing them at high component count could be too slow to do if updater can't process all components in the duration of an interval.

I have tested this and it has the same behavior like my previous code, so this is better to keep.

[pront]

Thanks!