Keep a cloud channel's listing in step with its compute service
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 25/100
- Type d'issue
- Bug
- Clarté
- Plutôt claire
- Activité
- Active
- Stack technique
- typescript
Piste de recherche
Start with the INACTIVITY threshold in services/compute/index.ts, then the Start compute and Stop compute handlers and the stopped flag in apps/host/src/compute.ts, to see how the host's record diverges from the service's state. Read docs/architecture.md (Cloud compute (beta)) for how busy and name reach the listing. Done means the listing and menu match the service after an inactivity stop, and busy and the current name show for cloud channels, verified on a deployed channel. Checkpointing (#413) is out of scope.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Follow-up to #216 and #428. A cloud channel's listing is set only by what this host itself does, so it drifts from the compute service.
- Inactivity stop:
services/computestops a container after 6 hours without activity (INACTIVITYinservices/compute/index.ts). The host'sstoppedflag changes only on its own Start compute and Stop compute (apps/host/src/compute.ts), so that channel still lists as running. Its menu offers only Stop compute, and Start compute on a running record fails with the service's "already running" error. Records created before #428 also list as running until their next start or stop. - Busy and name: busy and rename projections reach the listing over the workspace link, and a compute record has none. The listing shows a cloud channel idle under its created name until the channel's own metadata is read (docs/architecture.md, Cloud compute (beta)).
Remaining
- Reflect the service's actual running/stopped state, including an inactivity stop, in the record and listing, and offer the action that applies.
- Carry busy and the current name into the listing for cloud channels.
- Verify against the deployed service with a channel that the service stops for inactivity.
The inactivity stop doesn't checkpoint, so work since the last checkpoint is lost; that durability gap is #413. This issue only covers what the listing shows.
Tracked by #58.
- Langage dominant
- TypeScript
- Étoiles
- 1
- Forks
- 0
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Propose un modèle de pull request
- Aucun guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de githubnext/ace2
-
Difficulté 2/5 1-3 heures Accessibilité débutants 67/100
githubnext/ace2#459 ·
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 88/100
githubnext/ace2#437 ·
-
Difficulté 4/5 3-5 jours Accessibilité débutants 35/100
githubnext/ace2#442 ·
-
Difficulté 3/5 1-2 jours Accessibilité débutants 40/100
githubnext/ace2#440 ·
-
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 18/100
githubnext/ace2#429 ·
Toutes les issues de githubnext/ace2
Issues similaires
-
Difficulté 2/5 1-3 heures Accessibilité débutants 86/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 90/100
chrisparsons83/flexspotff#215 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
vitest-dev/vitest#11633 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 65/100
Les mainteneurs répondent en général sous 1 jour