Possession des sessions de nœuds OxideTerm

Utilisez cette compétence à chaque fois qu'un changement peut altérer quel composant crée, partage, ferme, reconnecte ou observe une session distante ou une tâche d'arrière-plan.

Invariant fondamental

Un nœud SSH connecté est indépendant de tout volet de terminal qui le consomme. La durée de vie de l'interface utilisateur ne doit pas devenir silencieusement la durée de vie du backend.

flowchart TD
    W["Durée de vie de l'espace de travail ou de l'application"] --> R["NodeRouter et registre de connexions"]
    R --> N["Connexion de nœud SSH physique"]
    N --> T["Consommateur terminal"]
    N --> S["Consommateur SFTP"]
    N --> F["Consommateur de redirection"]
    R --> H["Tâches de santé et de reconnexion"]

Règles obligatoires

La vivacité du nœud appartient au registre de connexions, à NodeRouter, ou à une opération explicite de déconnexion de nœud.
Fermer un volet de terminal supprime ce consommateur terminal. Il ne doit pas déconnecter un nœud partagé.
SFTP doit acquérir une session SFTP réelle adossée à un nœud. Une commande shell qui imite le transfert de fichier n'est qu'un repli de compatibilité documenté.
La redirection de ports possède ses propres tâches d'écoute et de pont. Ces tâches doivent rester actives sans volet de terminal ouvert et doivent s'arrêter lorsque la règle de redirection ou le nœud propriétaire s'arrête.
La reconnexion, les bilans de santé, les délais de grâce et les ponts de processus enfant nécessitent un propriétaire explicite et un chemin d'annulation lié à la durée de vie du nœud, de l'espace de travail ou de l'application.
Les tâches de longue durée ne doivent pas s'exécuter sur un runtime à usage unique qui est abandonné lorsqu'un gestionnaire de commande retourne.
Un nœud enfant connecté via un hôte de rebond doit conserver la connexion parente aussi longtemps que le transport enfant en a besoin.
Les composants de l'interface utilisateur observent l'état du runtime via des événements de routeur ou de registre. Ils ne doivent pas déduire la vivacité du nœud de l'existence d'un terminal.
Ajoutez des commentaires concis en anglais aux transferts de possession : création, partage, invalidation, réacquisition, annulation et survie délibérée après destruction de l'interface utilisateur.

Contournements interdits

N'ouvrez pas un deuxième transport SSH non géré parce qu'une API adossée à un nœud est peu pratique.
Ne trouvez pas une connexion en sélectionnant le premier volet de terminal associé à un hôte.
Ne stockez pas une tâche de longue durée uniquement dans une boîte de dialogue temporaire, un gestionnaire de commande ou une vue de terminal.
Ne marquez pas un nœud comme déconnecté simplement parce qu'un canal, volet, requête SFTP ou consommateur de redirection se ferme.
Ne laissez pas des processus enfants ou des tâches Tokio générés et détachés sans signal d'arrêt et chemin d'achèvement borné.

Pratiques recommandées

Exprimez chaque dépendance backend comme un consommateur ou un propriétaire dans le registre plutôt que de compter sur une rétention Arc incidente.
Conservez l'état du transport physique sur l'entrée de connexion et la topologie logique dans NodeRouter.
Faites en sorte que les cascades de déconnexion suivent les identités de connexion parent-enfant enregistrées, et non des chaînes d'hôte correspondantes.
Conservez les poignées de tâche ou les expéditeurs d'annulation sur l'objet dont la durée de vie définit la tâche.
Préférez les mises à jour de l'interface utilisateur pilotées par les événements plutôt que l'interrogation de l'état du terminal.

Chemins de compatibilité

Les replis de compatibilité ne sont autorisés que lorsqu'ils sont explicites, bornés et rapportés avec précision. Ils ne doivent pas être décrits comme une implémentation native SFTP, de redirection ou de session de nœud. Enregistrez le propriétaire et le chemin de nettoyage même pour les replis temporaires.

Exemples

Incorrect :

// La fermeture du volet détruit accidentellement le seul propriétaire du nœud partagé.
struct TerminalPane {
    ssh_transport: SshTransport,
}

Forme correcte :

// Le volet ne possède que son enregistrement de consommateur ; le registre possède la vivacité du transport.
struct TerminalPane {
    connection_id: String,
    terminal_consumer: ConnectionConsumer,
}

Incorrect :

tokio::runtime::Runtime::new()?.spawn(run_forward_listener());
// Le runtime est abandonné lorsque la commande retourne.

Forme correcte :

// Le propriétaire de la redirection conserve à la fois les poignées d'annulation et d'achèvement.
struct ForwardingJob {
    shutdown_tx: Option<oneshot::Sender<()>>,
    worker: JoinHandle<()>,
}

Liste de vérification pour la révision

Identifiez le propriétaire de la connexion physique.
Listez chaque consommateur terminal, SFTP, redirection, reconnexion, santé et nœud enfant.
Vérifiez que la fermeture d'un consommateur ne ferme pas des consommateurs non liés.
Vérifiez que la déconnexion explicite d'un nœud arrête les tâches dépendantes et les transports enfants.
Inspectez chaque tâche ou processus généré pour un propriétaire retenu, un signal d'annulation et un chemin de nettoyage.
Vérifiez que l'état de l'interface utilisateur consomme des événements de nœud plutôt que la vivacité dérivée du terminal.
Énoncez précisément tout repli de compatibilité restant.

Vérification

Fermez le dernier terminal et prouvez que le nœud reste utilisable par un autre consommateur enregistré.
Ouvrez SFTP sans nécessiter de volet de terminal.
Démarrez la redirection locale, distante et dynamique et vérifiez que les écouteurs survivent à la fermeture du volet.
Déconnectez un nœud parent et vérifiez que les nœuds enfants et tâches dépendants transitionnent de manière cohérente.
Reconnectez-vous dans le délai de grâce sans perdre d'état d'interface utilisateur non lié.
Confirmez que le nettoyage des tâches/processus se termine après une déconnexion explicite et un arrêt de l'application.

AnalyseDeCircuit/oxideterm

Qu'est-ce que oxideterm ?

Demander à votre IA préférée

Documentation