REL-NB-009 — Validate standalone Enterprise Gateway recovery
| Field | Value |
|---|---|
| Status | Open validation; expected deployment limitation |
| Architecture state | Source-backed recovery model; deployed one-replica topology |
| Severity | Operational boundary |
| Affected surface | Enterprise Gateway replacement and notebook reconnection |
| Components | sparqd/platform-stacks, Enterprise Gateway; sparqd/oqullus and sparqd/bff-api own client recovery |
| Associated issue | Not opened; open only if recovery fails or an agreed availability objective requires change |
Where the problem appears
Replace the sole Enterprise Gateway instance while a disposable remote kernel remains alive, then observe interruption and client recovery.
Concrete observed case
Source enables standalone availability with persisted kernel-session metadata.
A read-only check on 4 September 2026 confirmed one Enterprise Gateway, one Hub,
and one proxy instance in gj76anadpsc / w-t5e2kcxjd without automatic
scaling or disruption protection for them.
Expected condition
Gateway service can be briefly unavailable, but its replacement restores the same live remote kernel and the client reconnects without creating a duplicate or orphan SparkApplication. Any failure is visible and recoverable.
Cause and evidence
Standalone mode stores the connection information needed to rehydrate a remote kernel after gateway replacement. It does not keep a second gateway serving requests. Upstream describes standalone and replication availability modes as experimental.
Why it matters
Kernel survival, client recovery, and uninterrupted gateway service are different promises. Conflating them creates an unsupported availability claim.
Existing controls and workarounds
The remote Spark kernel can survive a gateway restart, and persistent session metadata supports reconnection. Users may still experience an interruption and must reconnect through Workspace.
Alternatives considered
- Recommended: retain standalone mode for the workspace-sized deployment, validate recovery, and vertically size it only when measurements require.
- Replication mode — consider only for a measured capacity need or explicit availability objective because shared state, affinity, failover, and client recovery must work together.
- Treat one replica as no recovery — rejected because standalone persistence is specifically designed to reconnect to surviving remote kernels.
Component involvement
sparqd/platform-stacksowns availability mode, persistence, rollout, and deployed capacity.sparqd/bff-apiandsparqd/oqullusown interruption and reconnection UX.- Enterprise Gateway restores the remote-kernel connection metadata.
Reproduction and verification
Follow NB-S011.
Resolution conditions
Record an agreed recovery objective and close validation when a controlled replacement retains kernel identity and variables, exposes interruption, and creates no duplicate or orphan workload.
Validation and blockers
Source and deployed topology are verified. An approved controlled gateway replacement remains outstanding.