Propiedad de la Sesión del Nodo OxideTerm

Use esta habilidad siempre que un cambio pueda alterar qué componente crea, comparte, cierra, reconecta u observa una sesión remota o un trabajo en segundo plano.

Invariante central

Un nodo SSH conectado es independiente de cualquier panel de terminal que lo consuma. La vida útil de la interfaz de usuario nunca debe convertirse silenciosamente en vida útil del backend.

flowchart TD
    W["Vida útil del espacio de trabajo o de la aplicación"] --> R["NodeRouter y registro de conexiones"]
    R --> N["Conexión física del nodo SSH"]
    N --> T["Consumidor de terminal"]
    N --> S["Consumidor SFTP"]
    N --> F["Consumidor de reenvío"]
    R --> H["Trabajos de salud y reconexión"]

Reglas obligatorias

La vida del nodo pertenece al registro de conexiones, NodeRouter o una operación explícita de desconexión del nodo.
Cerrar un panel de terminal elimina a ese consumidor de terminal. No debe desconectar un nodo compartido.
SFTP debe adquirir una sesión SFTP real respaldada por un nodo. Un comando de shell que imite la transferencia de archivos es solo una alternativa de compatibilidad documentada.
El reenvío de puertos posee sus tareas de escucha y puente. Esas tareas deben permanecer activas sin un panel de terminal abierto y deben detenerse cuando se detenga la regla de reenvío o el nodo propietario.
La reconexión, los controles de salud, los períodos de gracia y los puentes de procesos hijo necesitan un propietario explícito y una ruta de cancelación vinculada a la vida útil del nodo, espacio de trabajo o aplicación.
El trabajo de larga duración no debe ejecutarse en un tiempo de ejecución único que se descarte cuando un manejador de comandos retorna.
Un nodo hijo conectado a través de un host de salto debe conservar la conexión padre mientras el transporte hijo la necesite.
Los componentes de la interfaz de usuario observan el estado del tiempo de ejecución a través de eventos del enrutador o del registro. No deben inferir la vida del nodo a partir de la existencia de un terminal.
Agregue comentarios concisos en inglés en las transferencias de propiedad: creación, compartición, invalidación, readquisición, cancelación y supervivencia deliberada después del cierre de la interfaz de usuario.

Prohibiciones explícitas

No abra un segundo transporte SSH no gestionado porque una API basada en nodos sea inconveniente.
No encuentre una conexión seleccionando el primer panel de terminal asociado a un host.
No almacene una tarea de larga duración solo en un diálogo temporal, manejador de comandos o vista de terminal.
No marque un nodo como desconectado simplemente porque se cierre un canal, panel, solicitud SFTP o consumidor de reenvío.
No deje procesos hijo generados o tareas Tokio desvinculados sin una señal de apagado y una ruta de finalización acotada.

Prácticas recomendadas

Exprese cada dependencia del backend como un consumidor o propietario en el registro en lugar de confiar en la retención incidental de Arc.
Mantenga el estado del transporte físico en la entrada de conexión y la topología lógica en NodeRouter.
Haga que las cascadas de desconexión sigan las identidades registradas de conexión padre-hijo, no cadenas de host coincidentes.
Mantenga los manejadores de tareas o los remitentes de cancelación en el objeto cuya vida útil define el trabajo.
Prefiera actualizaciones de interfaz de usuario impulsadas por eventos en lugar de sondear el estado del terminal.

Rutas de compatibilidad

Las alternativas de compatibilidad solo están permitidas cuando son explícitas, acotadas y se informan con precisión. No deben describirse como una implementación nativa de SFTP, reenvío o sesión de nodo. Registre el propietario y la ruta de limpieza incluso para alternativas temporales.

Ejemplos

Incorrecto:

// Al cerrar el panel se destruye accidentalmente el único propietario del nodo compartido.
struct TerminalPane {
    ssh_transport: SshTransport,
}

Forma correcta:

// El panel posee solo su registro de consumidor; el registro posee la vida del transporte.
struct TerminalPane {
    connection_id: String,
    terminal_consumer: ConnectionConsumer,
}

Incorrecto:

tokio::runtime::Runtime::new()?.spawn(run_forward_listener());
// El tiempo de ejecución se descarta cuando el comando retorna.

Forma correcta:

// El propietario del reenvío conserva tanto los manejadores de cancelación como de finalización.
struct ForwardingJob {
    shutdown_tx: Option<oneshot::Sender<()>>,
    worker: JoinHandle<()>,
}

Lista de verificación de revisión

Identifique al propietario de la conexión física.
Enumere cada consumidor de terminal, SFTP, reenvío, reconexión, salud y nodo hijo.
Verifique que cerrar un consumidor no cierre consumidores no relacionados.
Verifique que la desconexión explícita del nodo detenga los trabajos dependientes y los transportes hijos.
Inspeccione cada tarea o proceso generado en busca de un propietario retenido, señal de cancelación y ruta de limpieza.
Verifique que el estado de la interfaz de usuario consuma eventos del nodo en lugar de vida derivada del terminal.
Indique cualquier alternativa de compatibilidad restante con precisión.

Verificación

Cierre el último terminal y demuestre que el nodo sigue siendo utilizable por otro consumidor registrado.
Abra SFTP sin requerir un panel de terminal.
Inicie reenvío local, remoto y dinámico y verifique que los oyentes sobrevivan al cierre del panel.
Desconecte un nodo padre y verifique que los nodos hijos dependientes y los trabajos transiten de manera consistente.
Reconéctese dentro del período de gracia sin perder el estado de la interfaz de usuario no relacionado.
Confirme que la limpieza de tareas/procesos se complete después de la desconexión explícita y el cierre de la aplicación.

AnalyseDeCircuit/oxideterm

¿Qué es oxideterm?

Preguntar en tu IA favorita

Documentación