Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Tracking: declare a concurrency scope per component so single-process components stay usable without blocking multi-replica deployments

Ouverte
  • Quelque chose ne va pas ?
#1,757 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 3 jours

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
38/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
Active
Stack technique
neo4j, postgresql, python, sqlite
Domaine
backend, distributed-systems

Piste de recherche

Read the related issues #1574, #1755, and #1756, plus the referenced design documents design/concurrency_scopes.md and design/server_redesign.md if available. Trace how components are constructed and how startup configuration is handled; the issue does not name implementation files or tests. Done means components declare composed concurrency scopes and startup rejects a component narrower than server.concurrency_scope, with a clear component-specific message.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

horizontal scaling keep-open

Priority 3 of the horizontal-scaling work (#1574), after the session lifecycle (#1755) and the background-work primitive (#1756). It is the smallest change of the three and unblocks keeping several components rather than removing them.

Why

Several components are correct in one process and wrong in several. The project wants to keep declarative memory for existing deployments and does not need it to scale, and does not depend on short-term memory at all. Routing requests by session so each replica owns its sessions does not deliver that: semantic sets are org-level and shared across projects (#1732), a failover loses the per-process state, and a routing layer is one more thing every later component must respect. A declared scope gives the same guarantee at boot, in one place, with no runtime cost.

At a glance
Component Today Scope to declare Issue
PostgreSQL segment store, episode store, session table safe from any replica CLUSTER done (#1661)
Qdrant and Milvus stores on the SQL registry safe from any replica after the chain CLUSTER #1733 to #1736
sqlite-vec store, SQLite SQL stores shared by one host's processes HOST #1733 scope statements
Engine-backed SQLite vector store one process per partition (in-process index) PROCESS #1733 scope statements
Short-term memory deque in process memory PROCESS #1748
Neo4j vector graph store, Nebula vector graph store (declarative memory) per-process caches PROCESS #1753
Neo4j semantic storage per-process set cache PROCESS #1753
Semantic memory as a whole ingestion loop in every replica PROCESS until #1745 lands, then CLUSTER #1745
Single fix

A ConcurrencyScope enum, PROCESS < HOST < CLUSTER, that every component computes from its parameters at construction and composes as the minimum of its parts. The deployment declares its own scope (server.concurrency_scope), and startup refuses any component narrower than the deployment, naming the component. Nothing is checked at runtime. Prior art: #1531 (closed) and design/concurrency_scopes.md on its branch; the scope round of design/server_redesign.md (#1579).

What this buys

Declarative memory and short-term memory stay as they are for single-replica deployments, with no code change beyond the declaration. A multi-replica deployment fails at boot with a clear message instead of serving wrong answers. Each later fix (claimed ingestion, a database-backed short-term memory, a loaded Nebula schema) is a one-word scope change on the component.

Not part of this

Making any PROCESS component scale. Removing declarative memory or short-term memory; removal becomes a separate decision that this issue makes unnecessary.

Tracked
  • #1748
  • #1753
  • #1745 (declared PROCESS until the claim lands)

🤖 Written by Claude Code (Claude Fable 5.1) on behalf of @edwinyyyu.

Langage dominant
Python
Étoiles
3.1k
Forks
217
Merge moyen
2 j 19 h
PR mergées (30 j)
17

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de MemMachine/MemMachine

Toutes les issues de MemMachine/MemMachine

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.