Anchor PS replication service regexes; skip SSH-key settings off AMI

[claude]

Failures fixed (investigator)

• source: Percona-Lab/pmm-submodules#4515 — run 31689194439
• tests:
  • e2e_tests/tests/dashboards/mysql/mysqlDashboards.test.ts:144 / @pmm-ps-integration — PMM-T2029 Verify dashboard for MySQL Replication Summary
  • codeceptjs-e2e/tests/configuration/verifyPMMSettingsPageFunctionality_test.js:243 / @fb-settings — PMM-T1227 + PMM-T1338 Verify tooltip "Read more" links on PMM Settings page

Two unrelated failures, both in pmm-qa's own test code. Neither is a PMM regression.

1. @pmm-ps-integration PMM-T2029 — an unanchored regex selecting the source node

Error: Metrics without data are: IO thread running,SQL thread running,Replication delay,MySQL replication lag,Relay log space
    Expected length: 0
    Received length: 5
    at ../pages/dashboards/dashboards.page.ts:147   (verifyAllPanelsHaveData)

Every empty panel is a replica-status panel, and they are empty because the test opened the
dashboard for the source instead of the replica.

percona-server-setup.yml appends a random suffix to each service name
(random_service_name_value: "_{{ 99999 | random + 1 }}"), so the two services are
ps_pmm_replication_8_0_1_<random> and ps_pmm_replication_8_0_2_<random>. The test selected
the replica with the unanchored pattern ps_pmm_replication_.*_2, which also matches the
source whenever that random suffix starts with 2 — and getServiceDetailsByRegexAndParameters
returns filteredServices[0], the source, since it is registered first.

This run drew 290:

API order: ['ps_pmm_gr_8_0_1_85826', 'ps_pmm_gr_8_0_2_85826',
            'ps_pmm_replication_8_0_1_290', 'ps_pmm_replication_8_0_2_290', ...]
current regex matches: ['ps_pmm_replication_8_0_1_290', 'ps_pmm_replication_8_0_2_290']
-> test would select: ps_pmm_replication_8_0_1_290      # the source

Only the replica carries the metrics behind those five panels — confirmed on the reproduction
server, where mysql_slave_status_slave_io_running exists for exactly one service:

services WITH slave_status metrics:
   ps_pmm_replication_8_0_2_<random> = 1

That is also why this is intermittent rather than always red: a suffix in 1..99999 starts with
2 about 11% of the time, and PMM-T2029 passed in the two immediately preceding FB runs
(31633396444,
31651545058).

Fix: anchor the patterns. Two further call sites carry the identical latent defect and are
fixed the same way — they did not fail in this run:

• mysqlDashboards.test.ts:84 PMM-T324 uses ps_pmm_replication_.*_1, which mirrors the bug
  (it matches the replica whenever the suffix starts with 1).
• mysqlQanStoredMetrics.test.ts:25 PMM-T2030 "Verify QAN for PS Replica Instance" uses the
  same _2 pattern, so it can silently assert against the source.

The anchored form follows the idiom already used in tests/standalone/screenshots.global-setup.ts
(^rs101(_\d+)?$), and selects exactly one correct service for every name shape in use:

service name	_1 regex	_2 regex
ps_pmm_replication_8_0_1_290	✅	—
ps_pmm_replication_8_0_2_290	—	✅
ps_pmm_replication_8_0_1_55934	✅	—
ps_pmm_replication_8_0_2_199	—	✅
ps_pmm_replication_8_4_1 (no suffix)	✅	—
ps_pmm_gr_8_0_2_85826	—	—

This is deliberately not handled by adding the five panels to the dashboard's
noDataMetrics: the data is there, on the replica. Suppressing them would switch off a real
"MySQL Replication Summary shows nothing" signal for good.

2. @fb-settings PMM-T1227 — the SSH Key tab no longer exists off AMI

element (SSH key tooltip) still not visible after 10 sec
  waiting for locator('[data-testid=ssh-key-label-description]').first() to be visible
  at verifyReadMoreLink (tests/configuration/pages/pmmSettingsPage.js:594:28)

This is the FB's own change working as intended. The build under test is
PMM-15302-ha-remove-ssh-settings, and percona/pmm#5744
("PMM-15302 Show ssh key tab only in AMI deployment") renders the tab only for AMI and redirects
the route everywhere else:

const showSshKeyTab = version?.distributionMethod === DistributionMethod.ami;
if (!showSshKeyTab && tab === 'ssh-key') {
  return <Navigate to="/settings" replace />;
}

The FB server reports "distribution_method": "DISTRIBUTION_METHOD_DOCKER", so
/pmm-ui/settings/ssh-key redirects to /settings and the tooltip never appears.
getSubpageTooltips() walked that subpage unconditionally.

Fix: add serverApi.getDistributionMethod() and include the SSH-key subpage only on AMI,
using the version-gated idiom already in leftNavigation_test.js. PMM-T85 - Verify SSH Key Section Elements (@settings @grafana-pr, not run in this FB) is gated the same way — it is
the identical defect and would go red in nightly the moment #5744 lands.

This is not blocked on #5744: with the tab present (main today) the check is skipped, with
it absent (the FB, and main after #5744) it is skipped, and on AMI it still runs.

Verification

One throwaway Linode VM running the exact FB server image
perconalab/pmm-server-fb:PR-4515-b0470c2, digest sha256:9ecd3d39… — the same digest Launchable
recorded for the CI run — with the FB client tarball, the PS job's own WIZARD_ARGS
(--database ps,SETUP_TYPE=replication,MY_ROCKS=true --database ps,SETUP_TYPE=gr,QUERY_SOURCE=slowlog),
and Chromium 151.0.7922.34, the build CI reported.

PMM-T2029. The VM's own setup drew suffix 55934, under which the bug cannot fire and all four
@pmm-ps-integration tests passed — matching the two preceding green FB runs. To reproduce the
failing condition rather than wait for it, both services were re-registered with CI's exact drawn
names (_290), leaving the databases untouched:

Branch	mysqlDashboards.test.ts --grep @pmm-ps-integration, names …_290
main	PMM-T2029 failed — Metrics without data are: IO thread running,SQL thread running,Replication delay,MySQL replication lag,Relay log space, identical to CI including the follow-on MySQL replication lag legend timeout
this branch	4 passed

PMM-T1227, same VM, same image:

Branch	codeceptjs run --grep PMM-T1227
main	failed — element (SSH key tooltip) still not visible after 10 sec, identical to CI
this branch	1 passed (the run stops after the Advisors tooltip; it no longer visits /settings/ssh-key)

PMM-T85 also passes on this branch against the same Docker deployment.

npx tsc --noEmit and ESLint are clean for the changed files.

Not covered by the above, and only the next real run can confirm: PMM-T324/PMM-T2030 under a
suffix that would have triggered their mirrored defect, and any AMI deployment, where the SSH-key
checks now take the branch that still asserts the tab.

Other failures in that run

None — these two checks were the only failures; the other 46 latest check-runs on
b0470c22b5db77adb9b0dc5d702292acfd37468f are green.

---

Generated by Claude Code