Module gotify 

The Gotify seam on Workspace: the forge.toml [gotify] config accessor, subscription CRUD (durable rows in the redb store, ephemeral ones in memory), the subsystem start/stop lifecycle, and the GotifyHost port impl the forge-connectors pump drives.

Everything here stays on Workspace as a second impl block, so every caller (the boot path in crate::workspace, the mcp::gotify facade, spawn::deliver_gotify_message, the Inspector GOTIFY snapshot) keeps its path. The gotify_* fields these methods own are pub(crate) for the same reason db is: so this sibling module can reach them without a wrapper. Stream, matching and the pump live in forge_connectors::gotify; store IO in crate::store::gotify; the MCP tool surface in crate::mcp::gotify; delivery in crate::spawn.

Re-exports

use std::collections::HashMap; 🔒

use std::sync::Arc; 🔒

use std::time::Duration; 🔒

use forge_connectors::gotify::GotifyHost; 🔒

use forge_primitives::GotifySubscription; 🔒

use crate::protocol::Command; 🔒

use crate::protocol::SessionUpdate; 🔒

use crate::target::ProjectKey; 🔒

use crate::workspace::Workspace; 🔒

Structs

GotifyExitGuard 🔒

Clears a finished pump’s handle and liveness when its task ends.

GotifySubsystem 🔒

One running Gotify pump as the workspace stores it: the shutdown signal plus the token that tells this run from a later one.

SubsystemHost 🔒

The GotifyHost the forge-connectors pump drives: a Weak<Workspace> behind the port. The pump holds the host strongly, so the wrapper stays the weak boundary - the workspace can drop while the subsystem runs, and every port call degrades to a no-op then, exactly like the per-event upgrade the pump did when it lived here.

Functions

url_host 🔒

The host a configured Gotify url names, for a log line: the scheme’s authority and nothing after it, so the client token never rides along.