[nanocore] Define the deferred multi-process scheduling and failover contract

Aperta
  • Qualcosa non va?
#176 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
8/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Ambito
backend

Direzione di ricerca

Start with the owning specification docs/specs/20260703-durable_scheduler_design.md and the decision record docs/decisions/20261006-execution_backend_port_in_nanocore.md to see what is already deferred. The work is a design decision, not a code change: an approved design must name one durable execution authority, its failover boundary, and how duplicate effects are prevented. It needs engineer approval and a governing owner amendment before any implementation starts.

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

Descrizione

question

Summary

Define the deferred multi-process scheduling and failover contract.

Category

decision needed

Area

Execution backend and scheduling

Observed behavior and evidence

Multi-process Core, shared scheduler state, high availability and hot failover are named deferred design work. Current in-process claims and one-Core ownership do not promise them. The Deferred / Future Work section is present on main 3a54ea25. No implementation conformance is claimed.

Impact

Severity: important. Explicitly deferred design scope; this is a backlog decision, not an rc.1 blocker or implementation authorization.

Suggested improvement

Establish the desired availability outcome and accepted failure model before choosing shared state or failover machinery. Amend the scheduler, storage and runtime owners with engineer approval and prove fencing before production implementation. Owning specification: docs/specs/20260703-durable_scheduler_design.md. A governing owner amendment and engineer approval are required before implementation.

Acceptance criteria

  • The approved design identifies one durable execution authority and its failover boundary.
  • Competing owners and unknown backend acceptance cannot create duplicate effects.
  • Retained data continuity and recovery can be verified after the selected failure scenarios.

References

  • docs/specs/20260703-durable_scheduler_design.md
  • docs/decisions/20261006-execution_backend_port_in_nanocore.md

Filed from the v0.1.0 acceptance-program inventory.

Lingua principale
TypeScript
Stelle
0
Fork
1
Merge medio
3h 54m
PR unite (30g)
5

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 lingkaix/openkit

Tutte le issue di lingkaix/openkit

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.