Files
star-map/e2e/neighbour-jump.spec.ts
T
SenrokaiandClaude Opus 5 f14e252b19 Name the neighbours that have a name, before the ones that only have a number
The neighbour ring exists to say where you are. Since the catalogue refresh it
has been spending one of its four places in Sol on "Gaia DR3 5853498713190525696"
-- a nineteen-digit survey id for the star printed beside it as Proxima
Centauri, the same star twice -- and that duplicate row pushed Barnard's Star
off the ring altogether. 91.9% of the refreshed catalogue is named that way.

Named stars now come first, and survey designations fill in only where fewer
than four named ones are in reach. The line between the two is the one the
catalogue format already draws: a name is a designation when it is what the
star's source would generate for it. Judged by the prefix rather than by
rebuilding "prefix id" from the row, because the number after "Gaia DR3" is the
survey's own id, which the 32-bit row id cannot hold -- a round trip through
the id would have called every one of those stars named.

The preference lives on the index as `nearestPreferring`: the preferred pass
exhausts the search before the fill runs, so a named star is never outranked by
a nearer unnamed one. That is the whole point of asking.

The end-to-end spec names Barnard's Star again, on purpose. The four nearest
named stars to the Sun are a fact about space, not about which catalogue was
refreshed last, and without this change that is exactly the label that
vanished -- checked by running the spec with the preference stashed: it fails
on that line, and passes with it back.

npm test 609/609, npx playwright test 16/16 under CI=true --workers=2.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014fcUfL82nvyh9VebX1Fz6w
2026-08-27 20:06:04 +02:00

38 lines
2.1 KiB
TypeScript

import { expect, test } from '@playwright/test';
import { openSearch } from './support/open-search';
test.describe('Neighbour jump', () => {
test('a neighbour named from inside one system flies into that one', async ({ page }) => {
// Two full camera flights on a software rasterizer shared with the rest of the suite: into
// Sol, then out and into the star its label names. See the same note on camera-flight.
test.setTimeout(120_000);
await page.goto('/?stars=4000');
const searchInput = await openSearch(page);
await searchInput.fill('Sol');
await page.getByRole('button', { name: /^Sol\b/ }).first().click();
const readout = page.getByTestId('hud-title');
await expect(readout).toHaveText('Sol', { timeout: 30_000 });
// Its nearest neighbours are named around the edge of the view; each is a button that flies
// there. Barnard's Star by name, on purpose: the ring ranks named stars ahead of survey
// designations, and the four nearest named to the Sun — Proxima, Rigil Kentaurus, Toliman,
// Barnard's — are a fact about space, not about which catalogue was refreshed last. Before
// that preference, a Gaia row duplicating Proxima took fourth place and this very label was
// the one that vanished, so it is also the regression test for it. Barnard's rather than the
// Alpha Centauri trio because those three share one bearing and are decluttered down to
// whichever the label pass reaches first.
const neighbour = page.getByRole('button', { name: /Barnard's Star/ });
await expect(neighbour).toBeVisible({ timeout: 30_000 });
await neighbour.click();
await expect(readout).toHaveText("Barnard's Star", { timeout: 45_000 });
// And from there the walk goes on: the new system names its own neighbours. Which ones is
// not asserted — several of Barnard's nearest share a bearing, so which of them survives
// the declutter is a property of the view, not a fact about the catalogue.
await expect(page.locator('.map-label--ghost')).not.toHaveCount(0, { timeout: 30_000 });
});
});