hyp session ignore saves nothing on a poll-source-only install: the idle gateway binds no port and the database-only fallback does not apply
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 35/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- javascript, postgresql, sqlite
Direzione di ricerca
Start in copilot/src/session.js, where the DATABASE_ONLY map and the session ignore, unignore and status commands live, and read the LLP 0549 #session-controls fallback rule it implements. Reproduce with a sandbox install whose only recorders are poll sources, then run hyp session ignore on a known id. Done when the commands fall back to the durable SessionIgnoreSet when the gateway has no upstreams and no recorder advertises the control route, a test covers that case, and listening recorders still fail closed with UNKNOWN.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Problem
hyp session ignore <id> saves nothing on an install whose only recorders read a native database by polling (Goose, Antigravity), and it exits 3 (status unknown).
These sources register no client of their own, or no database-only client, so the ai-gateway session command handles the request. On such an install hyp setup configures @hypaware/ai-gateway with upstreams: []. The gateway is started but idle and binds no port, so the command finds no recorder to reach:
$ hyp session ignore 20261103_3
hyp session: gateway at http://127.0.0.1:18621: could not reach the HypAware gateway ... ECONNREFUSED
exit 3
$ hyp session status 20261103_3
UNKNOWN, exit 3
With listen unpinned, the command fails earlier with "could not resolve the HypAware gateway endpoint", and the exit code is the same.
The poll sources already read the durable SessionIgnoreSet the gateway would have written. The only thing missing is a way for the CLI to write that set.
LLP 0549 #session-controls falls back to the store directly only when "every registered client is a database-only recorder ... and no gateway capability is active". An idle gateway still counts as active, and Goose and Antigravity are not in the DATABASE_ONLY map in copilot/src/session.js.
Found
T9 Linux run of the Goose integration (PR #2859), in a sandbox install with the Goose source only. Artifact: the 27-ignore.txt receipt in the mission folder. #2859 changes the Goose docs and LLP 0570 #privacy to say this, and points users at hyp privacy ignore <working dir>. The T9 sandbox checked that this works: after it, the session's rows were removed on the next import.
Expected
On an install where no recorder is listening and the gateway has no upstreams, hyp session ignore, unignore and status with an explicit native id write and read the durable store. They should give the same persisted_set_membership receipt that the Copilot/NanoClaw path gives.
Done when
- The session commands fall back to the durable store when the live snapshot shows the gateway idle (no upstreams) and no other recorder advertises the control route. A test covers that case.
- Any recorder that is listening keeps today's fail-closed UNKNOWN when it cannot be reached.
- The Goose and Antigravity docs drop the workaround note.
- Lingua principale
- JavaScript
- Stelle
- 11
- Fork
- 0
- Merge medio
- 2h 15m
- PR unite (30g)
- 322
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di hyparam/hypaware
-
Windows flake: withFileLock throws EPERM when the previous holder's lock file is still being deletedAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 79/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
hyparam/hypaware#2922 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
hyparam/hypaware#2918 · 3 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di hyparam/hypaware
Issue simili
-
binding:python bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
bug needs-triage potential-regression
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
aws/aws-sdk-js-v3#8408 ·
I maintainer di solito rispondono entro 1 giorno
-
[v3] KeyBindingManager calls (Add/Remove) are not converted into a case-insensitive accelerator.KeyApertaBug
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 4 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100