Memory pressure: the console shows a worker's step

Abierto
#1,365 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
74/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
typescript

Línea de trabajo

Start with ui/src/model/fleet.ts, worker-page.ts, and stale-keys.ts; the issue identifies each model seam and the corresponding tests. Read the referenced tests and ui/AGENTS.md first, then run the listed Vitest command. Done means the step appears with its word and tone in the Fleet square and Memory card, the event marks workers stale, and the unit tests and pnpm lint pass.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

task:ready

Part of #1355.

Scope

An operator sees a worker's memory-pressure step in the console. The Fleet row's square names it, and the worker page's Memory card has a row for it, on a gateway and on a standalone worker alike. A memory.pressure-changed event refreshes what the console shows.

In short

flowchart LR
  S[status.get capacity.memoryPressure] --> F[Fleet row square: findings *new word*]
  S --> W[worker page Memory card: Paused row *new*]
  E[memory.pressure-changed] -->|*new* marks workers stale| S
Step Fleet square word and colour Worker page Memory card row
new-devices-paused new devices paused, red Paused: new devices (red)
warming-paused warming paused, amber Paused: warming (amber)
none, or no field nothing new no row
worker not connected nothing new: disconnected already wins, as today (ui/src/model/fleet.ts:31) no Memory card, as today

The square still shows the worst finding, and each colour keeps its word. Of two findings with the same colour the square shows the first (F7), so the step's finding goes before the pressure and figure findings: at warming-paused with memory pressure warn the square reads warming paused, and at new-devices-paused with memory pressure critical it reads new devices paused.

If this goes wrong, the console shows a worker as calm while it refuses new devices, or the other way round.

Technical spec

Facts

Commit 6674ad0c.

# Fact Source
F1 The Fleet row's findings come from loadFindings: none for a worker not connected; memory pressure warn/critical with tone warn/error ui/src/model/fleet.ts:45-65
F2 The worker page's Memory card takes its tone from the pressure and lists a Pressure detail row ui/src/model/worker-page.ts:207-211, ui/src/model/worker-page.ts:233-245
F3 An event's stale keys come from staleKeys; capacity.changed marks the workers key; no test file covers it ui/src/model/stale-keys.ts:18-31, rg -l "staleKeys" ui/src e2e printed only stale-keys.ts and ui/src/state/queries.ts
F4 The Fleet tests cover the square's findings, pressure included ui/src/model/fleet.test.ts:84
F5 The console page documents the square's colours and words website/src/content/docs/docs/worker/console.mdx:104-108
F6 Colour is never the only signal; orange is never a state ui/AGENTS.md (Look)
F7 workerHealth keeps the first finding of the worst tone; loadFindings pushes the pressure finding last ui/src/model/fleet.ts:19-22, ui/src/model/fleet.ts:46-65
Modules touched

Searches: loadFindings, pressureStatus, figureCards, staleKeys, capacity.changed in ui/src.

flowchart LR
  SC[screens fleet, worker page] --> ST[state hooks]
  ST --> M1[model fleet.ts *]
  ST --> M2[model worker-page.ts *]
  Q[state queries.ts] --> M3[model stale-keys.ts *]
  • ui/src/model/fleet.ts: a finding from worker.capacity?.memoryPressure, placed before the pressure and figure findings (F7).
  • ui/src/model/worker-page.ts: the Paused detail row on the Memory card.
  • ui/src/model/stale-keys.ts: memory.pressure-changed marks the workers key; a new ui/src/model/stale-keys.test.ts.
  • Docs: website worker/console.mdx (the square table), fleet-console.mdx if it lists the words.
Contract and event changes

none: the console reads capacity.memoryPressure (#1361) and memory.pressure-changed (#1361) as types only.

Other code on the same state

Searches: readers of worker.capacity and worker.load.memory in ui/src/model (fleet.ts, worker-page.ts, overview.ts).

  • overview.ts reads capacity figures for counts only, not the step; unchanged.
  • The pressure finding (F1) and the step finding can both show; the square takes the worse tone, as today.
  • On a gateway, the console sees a new step only after the gateway refreshes that worker's view; until #1364 adds the event to the gateway's refresh list, that is its 30 s tick. Accepted: no Depends on #1364.
  • #1145 and #1156 (other features' drafts) edit the staleKeys switch and worker-page.ts; whichever lands second rebases. No Depends on: they are not ready.
Failure modes

none: the change crosses no boundary and writes no state.

Rules in play
  • ui manual: "Colour is never the only signal"; every new tone carries its word.
  • ui manual: "src/model/ has no React and no network, so every rule is a plain unit test."
  • ui manual: "An event marks keys stale through src/model/stale-keys.ts."
Tests

The seam is the model builders, modelled on ui/src/model/fleet.test.ts and ui/src/model/worker-page.test.ts.

  • An operator's console shows a worker's step on its card and page: new-devices-paused error tone with words; warming-paused warn tone; warming-paused beside memory pressure warn reads warming paused; new-devices-paused beside memory pressure critical reads new devices paused; none nothing.
  • A memory.pressure-changed event marks the console's workers stale: the event marks workers; an unrelated event does not.

Done when

  • pnpm exec vitest run --project unit ui/src/model/fleet.test.ts ui/src/model/worker-page.test.ts ui/src/model/stale-keys.test.ts passes.
  • pnpm lint passes.

Out of scope

  • A new screen or a chart of the step over time.

Depends on

  • #1361

Written by an agent.

Lenguaje dominante
TypeScript
Estrellas
535
Forks
21
Merge medio
9 h 10 min
PR fusionados (30 d)
454

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de callstackincubator/simlock

Todos los issues de callstackincubator/simlock

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.