Skip to content

fix(containers): stop repeating a title fragment when several engines run - #3678

Merged
nicolargo merged 1 commit into
nicolargo:developfrom
ntdatt812:fix/containers-title-duplicate-fragment
Aug 26, 2026
Merged

nicolargo merged 1 commit into
nicolargo:developfrom
ntdatt812:fix/containers-title-duplicate-fragment

Conversation

@ntdatt812

Copy link
Copy Markdown
Contributor

One append in the wrong block

build_title assembles the containers header by appending fragments to a single list. The final append sits outside the branch that produces its message:

if len(self.stats) > 1:
    msg = f' {len(self.stats)}'
    ret.append(self.curse_add_line(msg))
    msg = f' sorted by {sort_for_human[self.sort_key]}'
    ret.append(self.curse_add_line(msg))
if not self.views['show_engine_name']:
    msg = f' (served by {self.stats[0].get("engine", "")})'
ret.append(self.curse_add_line(msg))      # ← outside the `if`

With one engine the branch runs and the append is right. With several engines the branch is skipped, msg still holds the fragment appended just above it, and appending it again repeats it in the header.

show_engine_name is set when the containers come from more than one engine:

if len({ct["engine"] for ct in self.stats}) > 1:
    show_engine_name = True

so this is exactly the Docker + Podman case.

Measured

Driving the real build_title:

containers engines title
2 2 CONTAINERS 2 sorted by CPU consumption sorted by CPU consumption
1 2 CONTAINERSCONTAINERS
2 1 CONTAINERS 2 sorted by CPU consumption (served by docker) ✓
1 1 CONTAINERS (served by docker) ✓

After the fix the first two read CONTAINERS 2 sorted by CPU consumption and CONTAINERS, and the two correct rows are unchanged.

The fix

Move the append inside its branch. Nothing is lost in the multi-engine case: maybe_add_engine_name_or_pod_line already adds a per-row Engine column there, which is why the header deliberately omits "(served by …)".

Tests

Six cases in tests/test_plugin_containers.py, driving build_title with the curses helpers stubbed:

  • several engines → the sort fragment appears once
  • several engines with a single container → the title appears once
  • one engine → (served by docker) still shown, with and without the count
  • the sort key is named in the title (memory consumption, container name)
  • a sweep asserting no fragment appears twice in any of the four combinations

Mutation-checked — putting the append back outside the branch turns 3 of the 6 red:

FAILED test_several_engines_do_not_repeat_the_sort_fragment
FAILED test_several_engines_with_one_container_do_not_repeat_the_title
FAILED test_no_fragment_appears_twice
3 failed, 12 passed

ruff check and ruff format --check clean on both files.

… run

build_title appends the pieces of the header to one list, and the last
append sits outside the branch that produces its message:

        if not self.views['show_engine_name']:
            msg = f' (served by {self.stats[0].get("engine", "")})'
        ret.append(self.curse_add_line(msg))

With one engine the branch runs and the append is correct. With several -
Docker and Podman on the same host, which is the only case
show_engine_name is True - the branch is skipped, msg still holds the
previous fragment, and appending it again repeats it.

Measured against the real build_title:

    2 containers, 2 engines -> 'CONTAINERS 2 sorted by CPU consumption sorted by CPU consumption'
    1 container,  2 engines -> 'CONTAINERSCONTAINERS'
    2 containers, 1 engine  -> 'CONTAINERS 2 sorted by CPU consumption (served by docker)'
    1 container,  1 engine  -> 'CONTAINERS (served by docker)'

Move the append inside the branch. The engine name genuinely has nothing
to add in the multi-engine case: maybe_add_engine_name_or_pod_line adds a
per-row Engine column there instead.
@nicolargo nicolargo added this to the Glances 4.5.7 milestone Aug 26, 2026
@nicolargo
nicolargo merged commit 5b41982 into nicolargo:develop Aug 26, 2026
17 of 19 checks passed
@nicolargo

Copy link
Copy Markdown
Owner

Thanks for the PR @ntdatt812

Just merged into develop.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants