Studio: opt-in full-text analytics controls and metric view

Aperta
  • Qualcosa non va?
#2,049 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
15/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
frontend, observability

Direzione di ricerca

Start with the analytics settings schema in configRootSchema.json, which currently rejects unknown analytics properties, and the existing Status analytics folder under src/features/instance/status/analytics. Confirm how get_analytics is called today before adding metric "fulltext". Done means the analytics.fullText keys validate with their defaults, the view shows disabled, unsupported and unavailable states separately, and the counter-delta tests in the issue pass. The core PR #3946 and the Harper-pro release are still drafts, so check their status before starting.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Problem

Harper's upcoming full-text analytics integration adds an opt-in fulltext metric and dynamic analytics.fullText configuration. Studio needs a discoverable way to enable and interpret it after a compatible Harper-pro release reaches Fabric.

Studio: full-text search in the schema editor, plus a search tester covers schemas, searches and readiness, not telemetry. Studio: settings forms, with Fabric-managed settings marked read-only owns generic forms. Reuse that work rather than creating another settings framework. Today's analytics settings schema rejects unknown analytics properties and does not list fullText.

Scope

  • Add capability-aware discovery and a full-text analytics view using the existing protected get_analytics operation with metric: "fulltext", instance command transport and Status analytics infrastructure. Preserve existing authorization and unsupported/error states.
  • Extend the settings schema and expose or link the relevant controls through the existing settings UI. Omit the block by default; do not silently enable collection when opening a dashboard.
analytics.fullText key Type Implied value / validation
enabled boolean false
intervalMilliseconds integer 60000; inclusive range 1000–2147483647
histograms boolean false
snapshotBytes boolean false

The core policy applies dynamically without reopening indexes. Operator collection and persistence also require analytics enabled on a writable node; analytics.aggregatePeriod: -1 or read-only mode disables operator demand. Explain these prerequisites and show disabled, unsupported and unavailable states separately. Coordinate any existing Studio save/restart behavior with the settings work; do not invent a native reopen requirement.

Interpretation and acceptance

  • Keep node/worker, index path, role method and series distinct. Use each row's sampledAt; rollups retain the latest observation per worker/index/role instead of averaging cumulative counters.
  • Preserve exact decimal-string counters and nanoseconds/bytes. Compute differences with BigInt, check safe numeric conversion for plotting, and establish a new baseline after reset, unavailable/incomplete coverage or counter decrease. Gaps are not zero activity.
  • Show availability, observation age, pending reader-byte measurements, incomplete coverage and worker-wide dropped-row counts. Distinguish cumulative counters from current queue/dispatched gauges; do not sum overlapping queue capacities or repeat worker-wide counts across indexes.
  • Optional histogram deltas cover only recording-enabled intervals. Do not invent percentiles or process/per-index resident-memory measurements from these snapshots.
  • Do not collect or introduce query text, terms, record IDs, users, raw cursors, filesystem paths or exception-message labels. Reuse the metric contract; add no new endpoint or public SDK for internal telemetry-consumer hooks.
  • Test opt-in defaults and dynamic changes, capability/permission failures, multiple workers and roles, exact counters above the safe-number range, resets, gaps, pending/error states and absent samples. Bound polling to the selected view and reuse existing query caching rather than adding parallel polls.

Dependencies and scheduling

Depends on the upcoming Harper core implementation PR and a compatible Harper-pro release deployed to Fabric. Add the core PR and actual first compatible release links when available; no release date or version is selected here. The wrapper contract is described in fulltext 0.9 observability.

This is a scoped Studio feature, not Fabric runtime implementation or generic settings-form work. No customer incident or security defect is alleged.

Comment generated by kAIle (GPT-6)

Integration PRs

Harper runtime: Add opt-in native full-text analytics #3946. Reference: Document opt-in full-text analytics and the 0.9 engine #789. Both remain draft; the compatible Harper-pro release is not yet established. Use the released public wrapper APIs through Harper; Studio should not call native handles directly.

Comment generated by kAIle (GPT-6)

Lingua principale
TypeScript
Stelle
5
Fork
4
Merge medio
1g 19h
PR unite (30g)
144

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di HarperFast/studio

Tutte le issue di HarperFast/studio

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.