Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

feat(cloud): per-project cloud remote (route a project to a different Engram Cloud server)

Aperta
  • Qualcosa non va?
#1,603 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
35/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
go, sqlite
Ambito
backend

Direzione di ricerca

Start with internal/cloudconfig/config.go and cmd/engram/main.go, then trace the autosync manager and sync-state handling in internal/store/store.go. The issue describes separate configuration, routing, cursor/lease, catch-up, and doctor changes; the linked fork PR chain and design notes provide implementation context. Done means project-specific remotes work for explicit commands and autosync, with global routing preserved and remote state validated.

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

Descrizione

priority:medium status:needs-review type:feature
🔍 Problem Description

The client assumes exactly one cloud remote, so every enrolled project syncs to the same Engram Cloud. There is no way to keep one project on a different server (per environment, client or team) without running separate local data directories.

Evidence on main @ a43183c:

💡 Proposed Solution

Keep the global server as the default and allow any project to be routed to its own server and token:

  • cloud.json gains an optional projects map: {"<project>": {"server_url": "...", "token": "..."}}. Projects not listed keep using the global config. The ENGRAM_CLOUD_SERVER / ENGRAM_CLOUD_TOKEN env overrides apply to the global remote only.
  • CLI: engram cloud config --project <name> --server <url> [--token <token>] and engram cloud config --project <name> --clear. engram cloud status lists the project remotes with masked tokens.
  • Explicit project-scoped commands (engram sync --cloud --project, upgrade/doctor) resolve the project's own remote.
  • Autosync runs one manager per distinct remote. Non-global remotes use their own sync state key (cloud@<remote-id>) for the pull cursor and lease; each manager pushes and pulls only its projects, and the global manager excludes routed projects.
  • The mutation journal stays a single target_key='cloud': each project has exactly one destination, so acknowledgements stay correct.
  • When a project's effective remote changes, its full local history is re-queued for the new remote and a catch-up pull runs. Nothing is deleted locally or on the previous remote.
  • A tokenless project override fails closed instead of sending unauthenticated requests.
  • doctor validates each remote's sync state and can clean up state left by remotes that are no longer used.
📦 Affected Area

Sync (multi-instance)

🔄 Alternatives Considered
  • One journal per remote: touches enqueue/ack/backfills/doctor in roughly 20 hardcoded places with no benefit while each project has a single destination.
  • Separate data directories per server: splits local memory and search across directories and requires switching config manually.
  • Server-side routing: pushes the concern onto the server and still needs one cursor per server on the client.
📎 Additional Context

Implemented and tested in a fork, merged as a stack: https://github.com/gonzalez962/engram/pull/3 (config overrides), #4 (explicit sync and CLI routing), #5 (one autosync manager per remote), #6 (catch-up pull on reroute and live remote state in doctor), #7 (doctor validation and cleanup of orphaned remote state). Design notes: #2.

This is the largest of the related changes, so I would land it as the same chain of PRs within the ~400-line review budget, in the order above.

Related: #1582, #1599, #1600 (managed cloud gaps found on the same deployment).

Lingua principale
Go
Stelle
7.1k
Fork
729
Merge medio
11h 26m
PR unite (30g)
291

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

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 Gentleman-Programming/engram

Tutte le issue di Gentleman-Programming/engram

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.