proto: Document that CheckLightningAvailability is monotonic

libs/gl-client-py/glclient/scheduler.proto

@@ -97,10 +97,14 @@ service Scheduler {
 	// node. There is therefore no mTLS identity to derive the node
 	// from, and the caller names the `node_id` it is asking about.
 	//
-	// The answer is advisory and may change: a node that is not
-	// available today may become available once the LSP has capacity
-	// again. Applications should treat an error as "unknown" rather
-	// than as a negative answer.
+	// The answer is monotonic: once a node has been registered
+	// with greenlight it is reported as available, and stays
+	// available regardless of the node's status or of the LSP's
+	// current capacity. Before registration the answer is
+	// advisory and may change: a node that is not available today
+	// may become available once the LSP has capacity again.
+	// Applications should treat an error as "unknown" rather than
+	// as a negative answer.
 	rpc CheckLightningAvailability(CheckLightningAvailabilityRequest) returns (CheckLightningAvailabilityResponse) {}
 
 	// Scheduling takes a previously registered node, locates a

libs/gl-client/CHANGELOG.md

@@ -8,7 +8,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 
 ### Added
 
-- `Scheduler::check_lightning_availability(node_id)` and the corresponding `Scheduler.CheckLightningAvailability` RPC — reports whether the Lightning account backed by `node_id` may be surfaced to the user. Unauthenticated and callable before the node is registered, so the `node_id` is passed explicitly rather than taken from the credentials.
+- `Scheduler::check_lightning_availability(node_id)` and the corresponding `Scheduler.CheckLightningAvailability` RPC — reports whether the Lightning account backed by `node_id` may be surfaced to the user. Unauthenticated and callable before the node is registered, so the `node_id` is passed explicitly rather than taken from the credentials. Monotonic: a registered node is always reported as available.
 
 ### Changed
 

libs/gl-client/src/scheduler.rs

@@ -113,8 +113,12 @@ impl<Creds> Scheduler<Creds> {
     /// therefore passed explicitly rather than taken from the
     /// credentials.
     ///
-    /// The answer is advisory and may change over time. Treat an
-    /// error as "unknown" rather than as a negative answer.
+    /// The answer is monotonic: once the node has been registered
+    /// it is reported as available, and stays available regardless
+    /// of the node's status or the provider's current capacity.
+    /// Before registration the answer is advisory and may change
+    /// over time. Treat an error as "unknown" rather than as a
+    /// negative answer.
     pub async fn check_lightning_availability(
         &self,
         node_id: Vec<u8>,

libs/gl-sdk/CHANGELOG.md

@@ -8,7 +8,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 
 ### Added
 
-- `Scheduler.lightning_available(node_id)` — asks whether the Lightning account backed by `node_id` may be surfaced to the user. Intended as a feature gate for applications that offer Lightning alongside other account types. Callable before `register()` and without credentials, since the decision has to be made before a node exists. The answer is advisory; treat an error as "unknown" rather than as a negative answer. Greenlight currently reports every account as unavailable while the backing Lightning Service Provider integration is being built.
+- `Scheduler.lightning_available(node_id)` — asks whether the Lightning account backed by `node_id` may be surfaced to the user. Intended as a feature gate for applications that offer Lightning alongside other account types. Callable before `register()` and without credentials, since the decision has to be made before a node exists. The answer is monotonic: once the node is registered it is reported as available and stays that way, whatever the node's status or the provider's capacity. Before registration the answer is advisory; treat an error as "unknown" rather than as a negative answer. Greenlight currently reports every unregistered account as unavailable while the backing Lightning Service Provider integration is being built.
 
 ## [0.4.0] - 2026-05-21
 

libs/gl-sdk/src/scheduler.rs

@@ -66,8 +66,12 @@ impl Scheduler {
     /// before it creates a node. It needs no credentials, and the
     /// `node_id` is passed explicitly.
     ///
-    /// The answer is advisory and may change over time. Treat an
-    /// error as "unknown" rather than as a negative answer.
+    /// The answer is monotonic: once the node has been registered
+    /// it is reported as available, and stays available regardless
+    /// of the node's status or the provider's current capacity.
+    /// Before registration the answer is advisory and may change
+    /// over time. Treat an error as "unknown" rather than as a
+    /// negative answer.
     pub fn lightning_available(&self, node_id: Vec<u8>) -> Result<bool, Error> {
         let nobody = self.nobody();
         exec(async move {

libs/gl-testing/gltesting/scheduler.py

@@ -87,8 +87,10 @@ def __init__(
         self.versions = enumerate_cln_versions()
         self.bitcoind = bitcoind
         self.invite_codes: List[str] = []
-        # Answer given to CheckLightningAvailability. Defaults to the
-        # production behaviour while no LSP is wired up: unavailable.
+        # Answer given to CheckLightningAvailability for nodes that
+        # are not registered. Defaults to the production behaviour
+        # while no LSP is wired up: unavailable. Registered nodes are
+        # always available, mirroring the real scheduler.
         self.lightning_available: bool = False
         self.next_webhook_id: int = 1
         self.received_invite_code = None
@@ -371,9 +373,13 @@ async def ListInviteCodes(self, req) -> schedpb.ListInviteCodesResponse:
     async def CheckLightningAvailability(
         self, req
     ) -> schedpb.CheckLightningAvailabilityResponse:
-        # Mirrors the real scheduler, which relays this to an LSP and
-        # reports unavailable while none is configured. Tests that care
-        # flip `lightning_available` on the fixture.
+        # Mirrors the real scheduler: a registered node is always
+        # available, so the answer never flips back once an
+        # application has acted on it. Anything else is relayed to an
+        # LSP, and reported unavailable while none is configured.
+        # Tests that care flip `lightning_available` on the fixture.
+        if any(n.node_id == req.node_id for n in self.nodes):
+            return schedpb.CheckLightningAvailabilityResponse(available=True)
         return schedpb.CheckLightningAvailabilityResponse(
             available=self.lightning_available
         )

libs/proto/glclient/scheduler.proto

@@ -97,10 +97,14 @@ service Scheduler {
 	// node. There is therefore no mTLS identity to derive the node
 	// from, and the caller names the `node_id` it is asking about.
 	//
-	// The answer is advisory and may change: a node that is not
-	// available today may become available once the LSP has capacity
-	// again. Applications should treat an error as "unknown" rather
-	// than as a negative answer.
+	// The answer is monotonic: once a node has been registered
+	// with greenlight it is reported as available, and stays
+	// available regardless of the node's status or of the LSP's
+	// current capacity. Before registration the answer is
+	// advisory and may change: a node that is not available today
+	// may become available once the LSP has capacity again.
+	// Applications should treat an error as "unknown" rather than
+	// as a negative answer.
 	rpc CheckLightningAvailability(CheckLightningAvailabilityRequest) returns (CheckLightningAvailabilityResponse) {}
 
 	// Scheduling takes a previously registered node, locates a