Add PaginatedKVStore support to VssStore by benthecarman · Pull Request #864 · lightningdevkit/ldk-node

benthecarman · 2026-04-01T21:26:32Z

Implement PaginatedKVStore and PaginatedKVStoreSync traits for VssStore, enabling paginated key listing via cursor-based pagination using PageToken.

At the moment VSS returns them in key order which is not ideal. We would need to add to the VSS server timestamps so they are returned in creation order. Ideally though after that change, it wouldn't require any changes on the client or in here because we have already hooked up the pagination. Curious on @tankyleo's thoughts here.

After this we'll have pagination for all the kv stores and can move forward with using it inside of ldk-node

ldk-reviews-bot · 2026-04-01T21:26:36Z

👋 Thanks for assigning @tankyleo as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

tnull

Ah, I had hoped that we could do this after lightningdevkit/rust-lightning#4323 lands, i.e., add it upstream directly. However, that PR seems to be delayed now as reviewer brought up more requirements, so probably need to go ahead here.

I'll let @tankyleo take a first look here and on the corresponding vss-server PR.

ldk-reviews-bot · 2026-04-04T00:00:49Z

🔔 1st Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-06T00:01:50Z

🔔 2nd Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

tankyleo · 2026-04-06T19:32:40Z

+ // VSS uses empty string to signal the last page
+ let next_page_token =
+ response.next_page_token.filter(|t| !t.is_empty()).map(PageToken::new);


Sounds to me like we should line-up the VSS API and the PaginatedKVStore API better, I raised a similar point in the VSS PR.
Right now a VSS could return a non-empty keys list, but signal "no more data to give" with a String::new() for the page token.
A consumer of PaginatedKVStore does another roundtrip, but the VSS did not expect any further roundtrips.

Yeah I feel like page_token: None should just be the signal that there is no more. That's what we do in the file system store and sqlite. Should fix that on the vss-server side but we can keep this is_empty check for safety.

Changed in lightningdevkit/vss-server#96 to do this

Yeah I feel like page_token: None should just be the signal that there is no more. That's what we do in the file system store and sqlite. Should fix that on the vss-server side but we can keep this is_empty check for safety.
I think we're following protobuf's/Google's best practices here. https://google.aip.dev/158 states:
Response messages for collections should define a string next_page_token field, providing the user with a page token that may be used to retrieve the next page.
The field containing pagination results should be the first field in the message and have a field number of 1. It should be a repeated field containing a list of resources constituting a single page of results.
If the end of the collection has been reached, the next_page_token field must be empty. This is the only way to communicate "end-of-collection" to users.
If the end of the collection has not been reached (or if the API can not determine in time), the API must provide a next_page_token.

tankyleo · 2026-04-06T19:39:05Z

+ match response.next_page_token {
+ Some(token) => page_token = Some(token),
+ None => break,
+ }


hmm here we determine whether we are done with pagination based on whether the page token is None, and not whether the list is empty. I guess just looking for clarification on the PaginatedKVStore API :)

Update to handle empty string

benthecarman · 2026-04-08T19:59:56Z

Okay updated to be compliant with the AIP 158 stuff

tankyleo · 2026-04-09T22:50:51Z

+ PaginatedKVStoreSync::list_paginated(&store, ns, sub, page_token).unwrap();
+ all_keys.extend(response.keys);
+ match response.next_page_token {
+ Some(token) if !token.as_str().is_empty() => page_token = Some(token),


Sounds to me here we should break only if the page token field is None, and not if the token is Some(""), otherwise, some details of the VSS API are leaking past the PaginatedKVStore API ?

ah true, good catch

ghost

LGTM !

ghost · 2026-04-14T11:20:50Z

 Ok(keys)
 	}

+	async fn list_paginated_internal(


It seems this is duplicating a lot of the logic of list_all_keys. Rather than doing that, can we
move the logic to a new method called list_keys or similar that takes the paget oken
move the while page_token != Some("".to_string()) loop to list_internal, calling list_keys
hence have both list_internal and list_internal_paginated reuse the same list_keys code to avoid duplication

Done, also fixed a potential issue where if the VSS server returned None for the page token we could go into an infinite loop.

ghost

Looks good I think, but I do wonder if we now need protocol-level versioning for VSS, see lightningdevkit/vss-server#96 (review).

ghost · 2026-04-20T12:48:52Z

 }
- Ok(keys)
+
+ Ok((keys, response.next_page_token))


list_keys returns response.next_page_token raw, so both callers independently handle the Some("") case. Would be cleaner to normalize it in list_keys itself. What do you think?

ghost · 2026-04-28T12:00:57Z

@benthecarman Any update here?

ghost

As mentioned above, I think we should wait to land this until we have the protocol versioning in VSS Server, so we can require it here (and error out if not met) before attempting to use pagination and fail at runtime.

ghost · 2026-05-06T01:25:57Z

🔔 1st Reminder

Hey @Camillarhi! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-05-09T00:00:52Z

🔔 2nd Reminder

Hey @Camillarhi! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-01T00:01:47Z

🔔 12th Reminder

Hey @Camillarhi! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-11T19:58:57Z

Rebased and updated vss-client to the 0.6

ghost

Mostly looks good, just some minor comments.

Please also include an entry in the compatibility section of the pending CHANGELOG.md to note that users must upgrade VSS server before upgrading LDK Node.

ghost · 2026-06-12T08:09:31Z

 native-tls = { version = "0.2", default-features = false, optional = true }
 postgres-native-tls = { version = "0.5", default-features = false, features = ["runtime"], optional = true }
-vss-client = { package = "vss-client-ng", version = "0.5" }
+vss-client = { package = "vss-client-ng", version = "0.6" }


Given this version introduced new error types (namely version mismatch, but can't recall if there are others), we'll need to update our retry policy to not retry if we hit a version mismatch, as it's unrecoverable.

Fixed. Looks like it would have failed before but now has better and more explicit error message

No, not what I meant: we need to update
fn retry_policy() -> CustomRetryPolicy{
above to skip_retry_on_error for VSSVersionMismatchError.

ghost · 2026-06-15T00:00:47Z

🔔 1st Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-15T00:00:59Z

🔔 1st Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Switches vss-client-ng to the crates.io 0.6 release. Generated with OpenAI Codex.

Move repeated VssStore construction logic into a shared build_vss_store() helper and have existing tests use it. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Extract the single-page VSS listing logic into a list_keys method that accepts page_token and page_size parameters. list_internal now drives the pagination loop itself, calling list_keys per page. This prepares for PaginatedKVStore support which will reuse list_keys for single-page queries. This also fixes a potential issue where if the VSS server returned None for the page token we could enter into an infinite loop. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

ghost · 2026-06-17T00:00:52Z

🔔 2nd Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-17T00:01:59Z

🔔 2nd Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost

LGTM a few nits/questions

ghost · 2026-06-17T00:21:32Z

- let mut keys = vec![];
+ secondary_namespace: &str, page_token: Option<String>, page_size: Option<i32>,
+	) -> io::Result<(Vec<String>, Option<String>)> {
 let key_prefix = self.build_obfuscated_prefix(primary_namespace, secondary_namespace);


We used to do this encryption once for the entire list, but now we do this once for every page. Encryption with chacha20 is fast so should be fine?

moved outside to be safe

ghost · 2026-06-17T00:23:35Z

+
+ const PAGE_SIZE: i32 = 50;
+
+ let vss_page_token = page_token.map(|t| t.to_string());


Thought we could do a into_inner instead of allocating a new string to copy a string, but realized this is gated behind the upstream API so should be fine for now.

ghost · 2026-06-18T08:10:06Z

Oh, seems cargo fmt didn't pass on this branch. Now fixed in #942. I miss CI.

benthecarman · 2026-04-01T21:26:32Z

Implement PaginatedKVStore and PaginatedKVStoreSync traits for VssStore, enabling paginated key listing via cursor-based pagination using PageToken.

At the moment VSS returns them in key order which is not ideal. We would need to add to the VSS server timestamps so they are returned in creation order. Ideally though after that change, it wouldn't require any changes on the client or in here because we have already hooked up the pagination. Curious on @tankyleo's thoughts here.

After this we'll have pagination for all the kv stores and can move forward with using it inside of ldk-node

ldk-reviews-bot · 2026-04-01T21:26:36Z

👋 Thanks for assigning @tankyleo as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

tnull

Ah, I had hoped that we could do this after lightningdevkit/rust-lightning#4323 lands, i.e., add it upstream directly. However, that PR seems to be delayed now as reviewer brought up more requirements, so probably need to go ahead here.

I'll let @tankyleo take a first look here and on the corresponding vss-server PR.

ldk-reviews-bot · 2026-04-04T00:00:49Z

🔔 1st Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-06T00:01:50Z

🔔 2nd Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

tankyleo · 2026-04-06T19:32:40Z

+ // VSS uses empty string to signal the last page
+ let next_page_token =
+ response.next_page_token.filter(|t| !t.is_empty()).map(PageToken::new);


Sounds to me like we should line-up the VSS API and the PaginatedKVStore API better, I raised a similar point in the VSS PR.
Right now a VSS could return a non-empty keys list, but signal "no more data to give" with a String::new() for the page token.
A consumer of PaginatedKVStore does another roundtrip, but the VSS did not expect any further roundtrips.

Yeah I feel like page_token: None should just be the signal that there is no more. That's what we do in the file system store and sqlite. Should fix that on the vss-server side but we can keep this is_empty check for safety.

Changed in lightningdevkit/vss-server#96 to do this

Yeah I feel like page_token: None should just be the signal that there is no more. That's what we do in the file system store and sqlite. Should fix that on the vss-server side but we can keep this is_empty check for safety.
I think we're following protobuf's/Google's best practices here. https://google.aip.dev/158 states:
Response messages for collections should define a string next_page_token field, providing the user with a page token that may be used to retrieve the next page.
The field containing pagination results should be the first field in the message and have a field number of 1. It should be a repeated field containing a list of resources constituting a single page of results.
If the end of the collection has been reached, the next_page_token field must be empty. This is the only way to communicate "end-of-collection" to users.
If the end of the collection has not been reached (or if the API can not determine in time), the API must provide a next_page_token.

tankyleo · 2026-04-06T19:39:05Z

+ match response.next_page_token {
+ Some(token) => page_token = Some(token),
+ None => break,
+ }


hmm here we determine whether we are done with pagination based on whether the page token is None, and not whether the list is empty. I guess just looking for clarification on the PaginatedKVStore API :)

Update to handle empty string

benthecarman · 2026-04-08T19:59:56Z

Okay updated to be compliant with the AIP 158 stuff

tankyleo · 2026-04-09T22:50:51Z

+ PaginatedKVStoreSync::list_paginated(&store, ns, sub, page_token).unwrap();
+ all_keys.extend(response.keys);
+ match response.next_page_token {
+ Some(token) if !token.as_str().is_empty() => page_token = Some(token),


Sounds to me here we should break only if the page token field is None, and not if the token is Some(""), otherwise, some details of the VSS API are leaking past the PaginatedKVStore API ?

ah true, good catch

ghost

LGTM !

ghost · 2026-04-14T11:20:50Z

 Ok(keys)
 	}

+	async fn list_paginated_internal(


It seems this is duplicating a lot of the logic of list_all_keys. Rather than doing that, can we
move the logic to a new method called list_keys or similar that takes the paget oken
move the while page_token != Some("".to_string()) loop to list_internal, calling list_keys
hence have both list_internal and list_internal_paginated reuse the same list_keys code to avoid duplication

Done, also fixed a potential issue where if the VSS server returned None for the page token we could go into an infinite loop.

ghost

Looks good I think, but I do wonder if we now need protocol-level versioning for VSS, see lightningdevkit/vss-server#96 (review).

ghost · 2026-04-20T12:48:52Z

 }
- Ok(keys)
+
+ Ok((keys, response.next_page_token))


list_keys returns response.next_page_token raw, so both callers independently handle the Some("") case. Would be cleaner to normalize it in list_keys itself. What do you think?

ghost · 2026-04-28T12:00:57Z

@benthecarman Any update here?

ghost

As mentioned above, I think we should wait to land this until we have the protocol versioning in VSS Server, so we can require it here (and error out if not met) before attempting to use pagination and fail at runtime.

ghost · 2026-05-06T01:25:57Z

🔔 1st Reminder

Hey @Camillarhi! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-05-09T00:00:52Z

🔔 2nd Reminder

Hey @Camillarhi! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-01T00:01:47Z

🔔 12th Reminder

Hey @Camillarhi! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-11T19:58:57Z

Rebased and updated vss-client to the 0.6

ghost

Mostly looks good, just some minor comments.

Please also include an entry in the compatibility section of the pending CHANGELOG.md to note that users must upgrade VSS server before upgrading LDK Node.

ghost · 2026-06-12T08:09:31Z

 native-tls = { version = "0.2", default-features = false, optional = true }
 postgres-native-tls = { version = "0.5", default-features = false, features = ["runtime"], optional = true }
-vss-client = { package = "vss-client-ng", version = "0.5" }
+vss-client = { package = "vss-client-ng", version = "0.6" }


Given this version introduced new error types (namely version mismatch, but can't recall if there are others), we'll need to update our retry policy to not retry if we hit a version mismatch, as it's unrecoverable.

Fixed. Looks like it would have failed before but now has better and more explicit error message

No, not what I meant: we need to update
fn retry_policy() -> CustomRetryPolicy{
above to skip_retry_on_error for VSSVersionMismatchError.

ghost · 2026-06-15T00:00:47Z

🔔 1st Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-15T00:00:59Z

🔔 1st Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Switches vss-client-ng to the crates.io 0.6 release. Generated with OpenAI Codex.

Move repeated VssStore construction logic into a shared build_vss_store() helper and have existing tests use it. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Extract the single-page VSS listing logic into a list_keys method that accepts page_token and page_size parameters. list_internal now drives the pagination loop itself, calling list_keys per page. This prepares for PaginatedKVStore support which will reuse list_keys for single-page queries. This also fixes a potential issue where if the VSS server returned None for the page token we could enter into an infinite loop. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

ghost · 2026-06-17T00:00:52Z

🔔 2nd Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-17T00:01:59Z

🔔 2nd Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost

LGTM a few nits/questions

ghost · 2026-06-17T00:21:32Z

- let mut keys = vec![];
+ secondary_namespace: &str, page_token: Option<String>, page_size: Option<i32>,
+	) -> io::Result<(Vec<String>, Option<String>)> {
 let key_prefix = self.build_obfuscated_prefix(primary_namespace, secondary_namespace);


We used to do this encryption once for the entire list, but now we do this once for every page. Encryption with chacha20 is fast so should be fine?

moved outside to be safe

ghost · 2026-06-17T00:23:35Z

+
+ const PAGE_SIZE: i32 = 50;
+
+ let vss_page_token = page_token.map(|t| t.to_string());


Thought we could do a into_inner instead of allocating a new string to copy a string, but realized this is gated behind the upstream API so should be fine for now.

ghost · 2026-06-18T08:10:06Z

Oh, seems cargo fmt didn't pass on this branch. Now fixed in #942. I miss CI.

benthecarman · 2026-04-01T21:26:32Z

Implement PaginatedKVStore and PaginatedKVStoreSync traits for VssStore, enabling paginated key listing via cursor-based pagination using PageToken.

At the moment VSS returns them in key order which is not ideal. We would need to add to the VSS server timestamps so they are returned in creation order. Ideally though after that change, it wouldn't require any changes on the client or in here because we have already hooked up the pagination. Curious on @tankyleo's thoughts here.

After this we'll have pagination for all the kv stores and can move forward with using it inside of ldk-node

ldk-reviews-bot · 2026-04-01T21:26:36Z

👋 Thanks for assigning @tankyleo as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

tnull

Ah, I had hoped that we could do this after lightningdevkit/rust-lightning#4323 lands, i.e., add it upstream directly. However, that PR seems to be delayed now as reviewer brought up more requirements, so probably need to go ahead here.

I'll let @tankyleo take a first look here and on the corresponding vss-server PR.

ldk-reviews-bot · 2026-04-04T00:00:49Z

🔔 1st Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-06T00:01:50Z

🔔 2nd Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

tankyleo · 2026-04-06T19:32:40Z

+ // VSS uses empty string to signal the last page
+ let next_page_token =
+ response.next_page_token.filter(|t| !t.is_empty()).map(PageToken::new);


Sounds to me like we should line-up the VSS API and the PaginatedKVStore API better, I raised a similar point in the VSS PR.
Right now a VSS could return a non-empty keys list, but signal "no more data to give" with a String::new() for the page token.
A consumer of PaginatedKVStore does another roundtrip, but the VSS did not expect any further roundtrips.

Yeah I feel like page_token: None should just be the signal that there is no more. That's what we do in the file system store and sqlite. Should fix that on the vss-server side but we can keep this is_empty check for safety.

Changed in lightningdevkit/vss-server#96 to do this

Yeah I feel like page_token: None should just be the signal that there is no more. That's what we do in the file system store and sqlite. Should fix that on the vss-server side but we can keep this is_empty check for safety.
I think we're following protobuf's/Google's best practices here. https://google.aip.dev/158 states:
Response messages for collections should define a string next_page_token field, providing the user with a page token that may be used to retrieve the next page.
The field containing pagination results should be the first field in the message and have a field number of 1. It should be a repeated field containing a list of resources constituting a single page of results.
If the end of the collection has been reached, the next_page_token field must be empty. This is the only way to communicate "end-of-collection" to users.
If the end of the collection has not been reached (or if the API can not determine in time), the API must provide a next_page_token.

tankyleo · 2026-04-06T19:39:05Z

+ match response.next_page_token {
+ Some(token) => page_token = Some(token),
+ None => break,
+ }


hmm here we determine whether we are done with pagination based on whether the page token is None, and not whether the list is empty. I guess just looking for clarification on the PaginatedKVStore API :)

Update to handle empty string

benthecarman · 2026-04-08T19:59:56Z

Okay updated to be compliant with the AIP 158 stuff

tankyleo · 2026-04-09T22:50:51Z

+ PaginatedKVStoreSync::list_paginated(&store, ns, sub, page_token).unwrap();
+ all_keys.extend(response.keys);
+ match response.next_page_token {
+ Some(token) if !token.as_str().is_empty() => page_token = Some(token),


Sounds to me here we should break only if the page token field is None, and not if the token is Some(""), otherwise, some details of the VSS API are leaking past the PaginatedKVStore API ?

ah true, good catch

ghost

LGTM !

ghost · 2026-04-14T11:20:50Z

 Ok(keys)
 	}

+	async fn list_paginated_internal(


It seems this is duplicating a lot of the logic of list_all_keys. Rather than doing that, can we
move the logic to a new method called list_keys or similar that takes the paget oken
move the while page_token != Some("".to_string()) loop to list_internal, calling list_keys
hence have both list_internal and list_internal_paginated reuse the same list_keys code to avoid duplication

Done, also fixed a potential issue where if the VSS server returned None for the page token we could go into an infinite loop.

ghost

Looks good I think, but I do wonder if we now need protocol-level versioning for VSS, see lightningdevkit/vss-server#96 (review).

ghost · 2026-04-20T12:48:52Z

 }
- Ok(keys)
+
+ Ok((keys, response.next_page_token))


list_keys returns response.next_page_token raw, so both callers independently handle the Some("") case. Would be cleaner to normalize it in list_keys itself. What do you think?

ghost · 2026-04-28T12:00:57Z

@benthecarman Any update here?

ghost

As mentioned above, I think we should wait to land this until we have the protocol versioning in VSS Server, so we can require it here (and error out if not met) before attempting to use pagination and fail at runtime.

ghost · 2026-05-06T01:25:57Z

🔔 1st Reminder

Hey @Camillarhi! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-05-09T00:00:52Z

🔔 2nd Reminder

Hey @Camillarhi! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-01T00:01:47Z

🔔 12th Reminder

Hey @Camillarhi! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-11T19:58:57Z

Rebased and updated vss-client to the 0.6

ghost

Mostly looks good, just some minor comments.

Please also include an entry in the compatibility section of the pending CHANGELOG.md to note that users must upgrade VSS server before upgrading LDK Node.

ghost · 2026-06-12T08:09:31Z

 native-tls = { version = "0.2", default-features = false, optional = true }
 postgres-native-tls = { version = "0.5", default-features = false, features = ["runtime"], optional = true }
-vss-client = { package = "vss-client-ng", version = "0.5" }
+vss-client = { package = "vss-client-ng", version = "0.6" }


Given this version introduced new error types (namely version mismatch, but can't recall if there are others), we'll need to update our retry policy to not retry if we hit a version mismatch, as it's unrecoverable.

Fixed. Looks like it would have failed before but now has better and more explicit error message

No, not what I meant: we need to update
fn retry_policy() -> CustomRetryPolicy{
above to skip_retry_on_error for VSSVersionMismatchError.

ghost · 2026-06-15T00:00:47Z

🔔 1st Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-15T00:00:59Z

🔔 1st Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Switches vss-client-ng to the crates.io 0.6 release. Generated with OpenAI Codex.

Move repeated VssStore construction logic into a shared build_vss_store() helper and have existing tests use it. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Extract the single-page VSS listing logic into a list_keys method that accepts page_token and page_size parameters. list_internal now drives the pagination loop itself, calling list_keys per page. This prepares for PaginatedKVStore support which will reuse list_keys for single-page queries. This also fixes a potential issue where if the VSS server returned None for the page token we could enter into an infinite loop. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

ghost · 2026-06-17T00:00:52Z

🔔 2nd Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-17T00:01:59Z

🔔 2nd Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost

LGTM a few nits/questions

ghost · 2026-06-17T00:21:32Z

- let mut keys = vec![];
+ secondary_namespace: &str, page_token: Option<String>, page_size: Option<i32>,
+	) -> io::Result<(Vec<String>, Option<String>)> {
 let key_prefix = self.build_obfuscated_prefix(primary_namespace, secondary_namespace);


We used to do this encryption once for the entire list, but now we do this once for every page. Encryption with chacha20 is fast so should be fine?

moved outside to be safe

ghost · 2026-06-17T00:23:35Z

+
+ const PAGE_SIZE: i32 = 50;
+
+ let vss_page_token = page_token.map(|t| t.to_string());


Thought we could do a into_inner instead of allocating a new string to copy a string, but realized this is gated behind the upstream API so should be fine for now.

ghost · 2026-06-18T08:10:06Z

Oh, seems cargo fmt didn't pass on this branch. Now fixed in #942. I miss CI.

benthecarman · 2026-04-01T21:26:32Z

Implement PaginatedKVStore and PaginatedKVStoreSync traits for VssStore, enabling paginated key listing via cursor-based pagination using PageToken.

At the moment VSS returns them in key order which is not ideal. We would need to add to the VSS server timestamps so they are returned in creation order. Ideally though after that change, it wouldn't require any changes on the client or in here because we have already hooked up the pagination. Curious on @tankyleo's thoughts here.

After this we'll have pagination for all the kv stores and can move forward with using it inside of ldk-node

ldk-reviews-bot · 2026-04-01T21:26:36Z

👋 Thanks for assigning @tankyleo as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

tnull

Ah, I had hoped that we could do this after lightningdevkit/rust-lightning#4323 lands, i.e., add it upstream directly. However, that PR seems to be delayed now as reviewer brought up more requirements, so probably need to go ahead here.

I'll let @tankyleo take a first look here and on the corresponding vss-server PR.

ldk-reviews-bot · 2026-04-04T00:00:49Z

🔔 1st Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-06T00:01:50Z

🔔 2nd Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

tankyleo · 2026-04-06T19:32:40Z

+ // VSS uses empty string to signal the last page
+ let next_page_token =
+ response.next_page_token.filter(|t| !t.is_empty()).map(PageToken::new);


Sounds to me like we should line-up the VSS API and the PaginatedKVStore API better, I raised a similar point in the VSS PR.
Right now a VSS could return a non-empty keys list, but signal "no more data to give" with a String::new() for the page token.
A consumer of PaginatedKVStore does another roundtrip, but the VSS did not expect any further roundtrips.

Yeah I feel like page_token: None should just be the signal that there is no more. That's what we do in the file system store and sqlite. Should fix that on the vss-server side but we can keep this is_empty check for safety.

Changed in lightningdevkit/vss-server#96 to do this

Yeah I feel like page_token: None should just be the signal that there is no more. That's what we do in the file system store and sqlite. Should fix that on the vss-server side but we can keep this is_empty check for safety.
I think we're following protobuf's/Google's best practices here. https://google.aip.dev/158 states:
Response messages for collections should define a string next_page_token field, providing the user with a page token that may be used to retrieve the next page.
The field containing pagination results should be the first field in the message and have a field number of 1. It should be a repeated field containing a list of resources constituting a single page of results.
If the end of the collection has been reached, the next_page_token field must be empty. This is the only way to communicate "end-of-collection" to users.
If the end of the collection has not been reached (or if the API can not determine in time), the API must provide a next_page_token.

tankyleo · 2026-04-06T19:39:05Z

+ match response.next_page_token {
+ Some(token) => page_token = Some(token),
+ None => break,
+ }


hmm here we determine whether we are done with pagination based on whether the page token is None, and not whether the list is empty. I guess just looking for clarification on the PaginatedKVStore API :)

Update to handle empty string

benthecarman · 2026-04-08T19:59:56Z

Okay updated to be compliant with the AIP 158 stuff

tankyleo · 2026-04-09T22:50:51Z

+ PaginatedKVStoreSync::list_paginated(&store, ns, sub, page_token).unwrap();
+ all_keys.extend(response.keys);
+ match response.next_page_token {
+ Some(token) if !token.as_str().is_empty() => page_token = Some(token),


Sounds to me here we should break only if the page token field is None, and not if the token is Some(""), otherwise, some details of the VSS API are leaking past the PaginatedKVStore API ?

ah true, good catch

ghost

LGTM !

ghost · 2026-04-14T11:20:50Z

 Ok(keys)
 	}

+	async fn list_paginated_internal(


It seems this is duplicating a lot of the logic of list_all_keys. Rather than doing that, can we
move the logic to a new method called list_keys or similar that takes the paget oken
move the while page_token != Some("".to_string()) loop to list_internal, calling list_keys
hence have both list_internal and list_internal_paginated reuse the same list_keys code to avoid duplication

Done, also fixed a potential issue where if the VSS server returned None for the page token we could go into an infinite loop.

ghost

Looks good I think, but I do wonder if we now need protocol-level versioning for VSS, see lightningdevkit/vss-server#96 (review).

ghost · 2026-04-20T12:48:52Z

 }
- Ok(keys)
+
+ Ok((keys, response.next_page_token))


list_keys returns response.next_page_token raw, so both callers independently handle the Some("") case. Would be cleaner to normalize it in list_keys itself. What do you think?

ghost · 2026-04-28T12:00:57Z

@benthecarman Any update here?

ghost

As mentioned above, I think we should wait to land this until we have the protocol versioning in VSS Server, so we can require it here (and error out if not met) before attempting to use pagination and fail at runtime.

ghost · 2026-05-06T01:25:57Z

🔔 1st Reminder

Hey @Camillarhi! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-05-09T00:00:52Z

🔔 2nd Reminder

Hey @Camillarhi! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-01T00:01:47Z

🔔 12th Reminder

Hey @Camillarhi! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-11T19:58:57Z

Rebased and updated vss-client to the 0.6

ghost

Mostly looks good, just some minor comments.

Please also include an entry in the compatibility section of the pending CHANGELOG.md to note that users must upgrade VSS server before upgrading LDK Node.

ghost · 2026-06-12T08:09:31Z

 native-tls = { version = "0.2", default-features = false, optional = true }
 postgres-native-tls = { version = "0.5", default-features = false, features = ["runtime"], optional = true }
-vss-client = { package = "vss-client-ng", version = "0.5" }
+vss-client = { package = "vss-client-ng", version = "0.6" }


Given this version introduced new error types (namely version mismatch, but can't recall if there are others), we'll need to update our retry policy to not retry if we hit a version mismatch, as it's unrecoverable.

Fixed. Looks like it would have failed before but now has better and more explicit error message

No, not what I meant: we need to update
fn retry_policy() -> CustomRetryPolicy{
above to skip_retry_on_error for VSSVersionMismatchError.

ghost · 2026-06-15T00:00:47Z

🔔 1st Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-15T00:00:59Z

🔔 1st Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Switches vss-client-ng to the crates.io 0.6 release. Generated with OpenAI Codex.

Move repeated VssStore construction logic into a shared build_vss_store() helper and have existing tests use it. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Extract the single-page VSS listing logic into a list_keys method that accepts page_token and page_size parameters. list_internal now drives the pagination loop itself, calling list_keys per page. This prepares for PaginatedKVStore support which will reuse list_keys for single-page queries. This also fixes a potential issue where if the VSS server returned None for the page token we could enter into an infinite loop. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

ghost · 2026-06-17T00:00:52Z

🔔 2nd Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-17T00:01:59Z

🔔 2nd Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost

LGTM a few nits/questions

ghost · 2026-06-17T00:21:32Z

- let mut keys = vec![];
+ secondary_namespace: &str, page_token: Option<String>, page_size: Option<i32>,
+	) -> io::Result<(Vec<String>, Option<String>)> {
 let key_prefix = self.build_obfuscated_prefix(primary_namespace, secondary_namespace);


We used to do this encryption once for the entire list, but now we do this once for every page. Encryption with chacha20 is fast so should be fine?

moved outside to be safe

ghost · 2026-06-17T00:23:35Z

+
+ const PAGE_SIZE: i32 = 50;
+
+ let vss_page_token = page_token.map(|t| t.to_string());


Thought we could do a into_inner instead of allocating a new string to copy a string, but realized this is gated behind the upstream API so should be fine for now.

ghost · 2026-06-18T08:10:06Z

Oh, seems cargo fmt didn't pass on this branch. Now fixed in #942. I miss CI.

benthecarman · 2026-04-01T21:26:32Z

Implement PaginatedKVStore and PaginatedKVStoreSync traits for VssStore, enabling paginated key listing via cursor-based pagination using PageToken.

At the moment VSS returns them in key order which is not ideal. We would need to add to the VSS server timestamps so they are returned in creation order. Ideally though after that change, it wouldn't require any changes on the client or in here because we have already hooked up the pagination. Curious on @tankyleo's thoughts here.

After this we'll have pagination for all the kv stores and can move forward with using it inside of ldk-node

ldk-reviews-bot · 2026-04-01T21:26:36Z

👋 Thanks for assigning @tankyleo as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

tnull

Ah, I had hoped that we could do this after lightningdevkit/rust-lightning#4323 lands, i.e., add it upstream directly. However, that PR seems to be delayed now as reviewer brought up more requirements, so probably need to go ahead here.

I'll let @tankyleo take a first look here and on the corresponding vss-server PR.

ldk-reviews-bot · 2026-04-04T00:00:49Z

🔔 1st Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-06T00:01:50Z

🔔 2nd Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

tankyleo · 2026-04-06T19:32:40Z

+ // VSS uses empty string to signal the last page
+ let next_page_token =
+ response.next_page_token.filter(|t| !t.is_empty()).map(PageToken::new);


Sounds to me like we should line-up the VSS API and the PaginatedKVStore API better, I raised a similar point in the VSS PR.
Right now a VSS could return a non-empty keys list, but signal "no more data to give" with a String::new() for the page token.
A consumer of PaginatedKVStore does another roundtrip, but the VSS did not expect any further roundtrips.

Yeah I feel like page_token: None should just be the signal that there is no more. That's what we do in the file system store and sqlite. Should fix that on the vss-server side but we can keep this is_empty check for safety.

Changed in lightningdevkit/vss-server#96 to do this

Yeah I feel like page_token: None should just be the signal that there is no more. That's what we do in the file system store and sqlite. Should fix that on the vss-server side but we can keep this is_empty check for safety.
I think we're following protobuf's/Google's best practices here. https://google.aip.dev/158 states:
Response messages for collections should define a string next_page_token field, providing the user with a page token that may be used to retrieve the next page.
The field containing pagination results should be the first field in the message and have a field number of 1. It should be a repeated field containing a list of resources constituting a single page of results.
If the end of the collection has been reached, the next_page_token field must be empty. This is the only way to communicate "end-of-collection" to users.
If the end of the collection has not been reached (or if the API can not determine in time), the API must provide a next_page_token.

tankyleo · 2026-04-06T19:39:05Z

+ match response.next_page_token {
+ Some(token) => page_token = Some(token),
+ None => break,
+ }


hmm here we determine whether we are done with pagination based on whether the page token is None, and not whether the list is empty. I guess just looking for clarification on the PaginatedKVStore API :)

Update to handle empty string

benthecarman · 2026-04-08T19:59:56Z

Okay updated to be compliant with the AIP 158 stuff

tankyleo · 2026-04-09T22:50:51Z

+ PaginatedKVStoreSync::list_paginated(&store, ns, sub, page_token).unwrap();
+ all_keys.extend(response.keys);
+ match response.next_page_token {
+ Some(token) if !token.as_str().is_empty() => page_token = Some(token),


Sounds to me here we should break only if the page token field is None, and not if the token is Some(""), otherwise, some details of the VSS API are leaking past the PaginatedKVStore API ?

ah true, good catch

ghost

LGTM !

ghost · 2026-04-14T11:20:50Z

 Ok(keys)
 	}

+	async fn list_paginated_internal(


It seems this is duplicating a lot of the logic of list_all_keys. Rather than doing that, can we
move the logic to a new method called list_keys or similar that takes the paget oken
move the while page_token != Some("".to_string()) loop to list_internal, calling list_keys
hence have both list_internal and list_internal_paginated reuse the same list_keys code to avoid duplication

Done, also fixed a potential issue where if the VSS server returned None for the page token we could go into an infinite loop.

ghost

Looks good I think, but I do wonder if we now need protocol-level versioning for VSS, see lightningdevkit/vss-server#96 (review).

ghost · 2026-04-20T12:48:52Z

 }
- Ok(keys)
+
+ Ok((keys, response.next_page_token))


list_keys returns response.next_page_token raw, so both callers independently handle the Some("") case. Would be cleaner to normalize it in list_keys itself. What do you think?

ghost · 2026-04-28T12:00:57Z

@benthecarman Any update here?

ghost

As mentioned above, I think we should wait to land this until we have the protocol versioning in VSS Server, so we can require it here (and error out if not met) before attempting to use pagination and fail at runtime.

ghost · 2026-05-06T01:25:57Z

🔔 1st Reminder

Hey @Camillarhi! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-05-09T00:00:52Z

🔔 2nd Reminder

Hey @Camillarhi! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-01T00:01:47Z

🔔 12th Reminder

Hey @Camillarhi! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-11T19:58:57Z

Rebased and updated vss-client to the 0.6

ghost

Mostly looks good, just some minor comments.

Please also include an entry in the compatibility section of the pending CHANGELOG.md to note that users must upgrade VSS server before upgrading LDK Node.

ghost · 2026-06-12T08:09:31Z

 native-tls = { version = "0.2", default-features = false, optional = true }
 postgres-native-tls = { version = "0.5", default-features = false, features = ["runtime"], optional = true }
-vss-client = { package = "vss-client-ng", version = "0.5" }
+vss-client = { package = "vss-client-ng", version = "0.6" }


Given this version introduced new error types (namely version mismatch, but can't recall if there are others), we'll need to update our retry policy to not retry if we hit a version mismatch, as it's unrecoverable.

Fixed. Looks like it would have failed before but now has better and more explicit error message

No, not what I meant: we need to update
fn retry_policy() -> CustomRetryPolicy{
above to skip_retry_on_error for VSSVersionMismatchError.

ghost · 2026-06-15T00:00:47Z

🔔 1st Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-15T00:00:59Z

🔔 1st Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Switches vss-client-ng to the crates.io 0.6 release. Generated with OpenAI Codex.

Move repeated VssStore construction logic into a shared build_vss_store() helper and have existing tests use it. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Extract the single-page VSS listing logic into a list_keys method that accepts page_token and page_size parameters. list_internal now drives the pagination loop itself, calling list_keys per page. This prepares for PaginatedKVStore support which will reuse list_keys for single-page queries. This also fixes a potential issue where if the VSS server returned None for the page token we could enter into an infinite loop. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

ghost · 2026-06-17T00:00:52Z

🔔 2nd Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-17T00:01:59Z

🔔 2nd Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost

LGTM a few nits/questions

ghost · 2026-06-17T00:21:32Z

- let mut keys = vec![];
+ secondary_namespace: &str, page_token: Option<String>, page_size: Option<i32>,
+	) -> io::Result<(Vec<String>, Option<String>)> {
 let key_prefix = self.build_obfuscated_prefix(primary_namespace, secondary_namespace);


We used to do this encryption once for the entire list, but now we do this once for every page. Encryption with chacha20 is fast so should be fine?

moved outside to be safe

ghost · 2026-06-17T00:23:35Z

+
+ const PAGE_SIZE: i32 = 50;
+
+ let vss_page_token = page_token.map(|t| t.to_string());


Thought we could do a into_inner instead of allocating a new string to copy a string, but realized this is gated behind the upstream API so should be fine for now.

ghost · 2026-06-18T08:10:06Z

Oh, seems cargo fmt didn't pass on this branch. Now fixed in #942. I miss CI.

benthecarman · 2026-04-01T21:26:32Z

Implement PaginatedKVStore and PaginatedKVStoreSync traits for VssStore, enabling paginated key listing via cursor-based pagination using PageToken.

At the moment VSS returns them in key order which is not ideal. We would need to add to the VSS server timestamps so they are returned in creation order. Ideally though after that change, it wouldn't require any changes on the client or in here because we have already hooked up the pagination. Curious on @tankyleo's thoughts here.

After this we'll have pagination for all the kv stores and can move forward with using it inside of ldk-node

ldk-reviews-bot · 2026-04-01T21:26:36Z

👋 Thanks for assigning @tankyleo as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

tnull

Ah, I had hoped that we could do this after lightningdevkit/rust-lightning#4323 lands, i.e., add it upstream directly. However, that PR seems to be delayed now as reviewer brought up more requirements, so probably need to go ahead here.

I'll let @tankyleo take a first look here and on the corresponding vss-server PR.

ldk-reviews-bot · 2026-04-04T00:00:49Z

🔔 1st Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-06T00:01:50Z

🔔 2nd Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

tankyleo · 2026-04-06T19:32:40Z

+ // VSS uses empty string to signal the last page
+ let next_page_token =
+ response.next_page_token.filter(|t| !t.is_empty()).map(PageToken::new);


Sounds to me like we should line-up the VSS API and the PaginatedKVStore API better, I raised a similar point in the VSS PR.
Right now a VSS could return a non-empty keys list, but signal "no more data to give" with a String::new() for the page token.
A consumer of PaginatedKVStore does another roundtrip, but the VSS did not expect any further roundtrips.

Yeah I feel like page_token: None should just be the signal that there is no more. That's what we do in the file system store and sqlite. Should fix that on the vss-server side but we can keep this is_empty check for safety.

Changed in lightningdevkit/vss-server#96 to do this

Yeah I feel like page_token: None should just be the signal that there is no more. That's what we do in the file system store and sqlite. Should fix that on the vss-server side but we can keep this is_empty check for safety.
I think we're following protobuf's/Google's best practices here. https://google.aip.dev/158 states:
Response messages for collections should define a string next_page_token field, providing the user with a page token that may be used to retrieve the next page.
The field containing pagination results should be the first field in the message and have a field number of 1. It should be a repeated field containing a list of resources constituting a single page of results.
If the end of the collection has been reached, the next_page_token field must be empty. This is the only way to communicate "end-of-collection" to users.
If the end of the collection has not been reached (or if the API can not determine in time), the API must provide a next_page_token.

tankyleo · 2026-04-06T19:39:05Z

+ match response.next_page_token {
+ Some(token) => page_token = Some(token),
+ None => break,
+ }


hmm here we determine whether we are done with pagination based on whether the page token is None, and not whether the list is empty. I guess just looking for clarification on the PaginatedKVStore API :)

Update to handle empty string

benthecarman · 2026-04-08T19:59:56Z

Okay updated to be compliant with the AIP 158 stuff

tankyleo · 2026-04-09T22:50:51Z

+ PaginatedKVStoreSync::list_paginated(&store, ns, sub, page_token).unwrap();
+ all_keys.extend(response.keys);
+ match response.next_page_token {
+ Some(token) if !token.as_str().is_empty() => page_token = Some(token),


Sounds to me here we should break only if the page token field is None, and not if the token is Some(""), otherwise, some details of the VSS API are leaking past the PaginatedKVStore API ?

ah true, good catch

ghost

LGTM !

ghost · 2026-04-14T11:20:50Z

 Ok(keys)
 	}

+	async fn list_paginated_internal(


It seems this is duplicating a lot of the logic of list_all_keys. Rather than doing that, can we
move the logic to a new method called list_keys or similar that takes the paget oken
move the while page_token != Some("".to_string()) loop to list_internal, calling list_keys
hence have both list_internal and list_internal_paginated reuse the same list_keys code to avoid duplication

Done, also fixed a potential issue where if the VSS server returned None for the page token we could go into an infinite loop.

ghost

Looks good I think, but I do wonder if we now need protocol-level versioning for VSS, see lightningdevkit/vss-server#96 (review).

ghost · 2026-04-20T12:48:52Z

 }
- Ok(keys)
+
+ Ok((keys, response.next_page_token))


list_keys returns response.next_page_token raw, so both callers independently handle the Some("") case. Would be cleaner to normalize it in list_keys itself. What do you think?

ghost · 2026-04-28T12:00:57Z

@benthecarman Any update here?

ghost

As mentioned above, I think we should wait to land this until we have the protocol versioning in VSS Server, so we can require it here (and error out if not met) before attempting to use pagination and fail at runtime.

ghost · 2026-05-06T01:25:57Z

🔔 1st Reminder

Hey @Camillarhi! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-05-09T00:00:52Z

🔔 2nd Reminder

Hey @Camillarhi! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-01T00:01:47Z

🔔 12th Reminder

Hey @Camillarhi! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-11T19:58:57Z

Rebased and updated vss-client to the 0.6

ghost

Mostly looks good, just some minor comments.

Please also include an entry in the compatibility section of the pending CHANGELOG.md to note that users must upgrade VSS server before upgrading LDK Node.

ghost · 2026-06-12T08:09:31Z

 native-tls = { version = "0.2", default-features = false, optional = true }
 postgres-native-tls = { version = "0.5", default-features = false, features = ["runtime"], optional = true }
-vss-client = { package = "vss-client-ng", version = "0.5" }
+vss-client = { package = "vss-client-ng", version = "0.6" }


Given this version introduced new error types (namely version mismatch, but can't recall if there are others), we'll need to update our retry policy to not retry if we hit a version mismatch, as it's unrecoverable.

Fixed. Looks like it would have failed before but now has better and more explicit error message

No, not what I meant: we need to update
fn retry_policy() -> CustomRetryPolicy{
above to skip_retry_on_error for VSSVersionMismatchError.

ghost · 2026-06-15T00:00:47Z

🔔 1st Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-15T00:00:59Z

🔔 1st Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Switches vss-client-ng to the crates.io 0.6 release. Generated with OpenAI Codex.

Move repeated VssStore construction logic into a shared build_vss_store() helper and have existing tests use it. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Extract the single-page VSS listing logic into a list_keys method that accepts page_token and page_size parameters. list_internal now drives the pagination loop itself, calling list_keys per page. This prepares for PaginatedKVStore support which will reuse list_keys for single-page queries. This also fixes a potential issue where if the VSS server returned None for the page token we could enter into an infinite loop. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

ghost · 2026-06-17T00:00:52Z

🔔 2nd Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-17T00:01:59Z

🔔 2nd Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost

LGTM a few nits/questions

ghost · 2026-06-17T00:21:32Z

- let mut keys = vec![];
+ secondary_namespace: &str, page_token: Option<String>, page_size: Option<i32>,
+	) -> io::Result<(Vec<String>, Option<String>)> {
 let key_prefix = self.build_obfuscated_prefix(primary_namespace, secondary_namespace);


We used to do this encryption once for the entire list, but now we do this once for every page. Encryption with chacha20 is fast so should be fine?

moved outside to be safe

ghost · 2026-06-17T00:23:35Z

+
+ const PAGE_SIZE: i32 = 50;
+
+ let vss_page_token = page_token.map(|t| t.to_string());


Thought we could do a into_inner instead of allocating a new string to copy a string, but realized this is gated behind the upstream API so should be fine for now.

ghost · 2026-06-18T08:10:06Z

Oh, seems cargo fmt didn't pass on this branch. Now fixed in #942. I miss CI.

benthecarman · 2026-04-01T21:26:32Z

Implement PaginatedKVStore and PaginatedKVStoreSync traits for VssStore, enabling paginated key listing via cursor-based pagination using PageToken.

At the moment VSS returns them in key order which is not ideal. We would need to add to the VSS server timestamps so they are returned in creation order. Ideally though after that change, it wouldn't require any changes on the client or in here because we have already hooked up the pagination. Curious on @tankyleo's thoughts here.

After this we'll have pagination for all the kv stores and can move forward with using it inside of ldk-node

ldk-reviews-bot · 2026-04-01T21:26:36Z

👋 Thanks for assigning @tankyleo as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

tnull

Ah, I had hoped that we could do this after lightningdevkit/rust-lightning#4323 lands, i.e., add it upstream directly. However, that PR seems to be delayed now as reviewer brought up more requirements, so probably need to go ahead here.

I'll let @tankyleo take a first look here and on the corresponding vss-server PR.

ldk-reviews-bot · 2026-04-04T00:00:49Z

🔔 1st Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-06T00:01:50Z

🔔 2nd Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

tankyleo · 2026-04-06T19:32:40Z

+ // VSS uses empty string to signal the last page
+ let next_page_token =
+ response.next_page_token.filter(|t| !t.is_empty()).map(PageToken::new);


Sounds to me like we should line-up the VSS API and the PaginatedKVStore API better, I raised a similar point in the VSS PR.
Right now a VSS could return a non-empty keys list, but signal "no more data to give" with a String::new() for the page token.
A consumer of PaginatedKVStore does another roundtrip, but the VSS did not expect any further roundtrips.

Yeah I feel like page_token: None should just be the signal that there is no more. That's what we do in the file system store and sqlite. Should fix that on the vss-server side but we can keep this is_empty check for safety.

Changed in lightningdevkit/vss-server#96 to do this

Yeah I feel like page_token: None should just be the signal that there is no more. That's what we do in the file system store and sqlite. Should fix that on the vss-server side but we can keep this is_empty check for safety.
I think we're following protobuf's/Google's best practices here. https://google.aip.dev/158 states:
Response messages for collections should define a string next_page_token field, providing the user with a page token that may be used to retrieve the next page.
The field containing pagination results should be the first field in the message and have a field number of 1. It should be a repeated field containing a list of resources constituting a single page of results.
If the end of the collection has been reached, the next_page_token field must be empty. This is the only way to communicate "end-of-collection" to users.
If the end of the collection has not been reached (or if the API can not determine in time), the API must provide a next_page_token.

tankyleo · 2026-04-06T19:39:05Z

+ match response.next_page_token {
+ Some(token) => page_token = Some(token),
+ None => break,
+ }


hmm here we determine whether we are done with pagination based on whether the page token is None, and not whether the list is empty. I guess just looking for clarification on the PaginatedKVStore API :)

Update to handle empty string

benthecarman · 2026-04-08T19:59:56Z

Okay updated to be compliant with the AIP 158 stuff

tankyleo · 2026-04-09T22:50:51Z

+ PaginatedKVStoreSync::list_paginated(&store, ns, sub, page_token).unwrap();
+ all_keys.extend(response.keys);
+ match response.next_page_token {
+ Some(token) if !token.as_str().is_empty() => page_token = Some(token),


Sounds to me here we should break only if the page token field is None, and not if the token is Some(""), otherwise, some details of the VSS API are leaking past the PaginatedKVStore API ?

ah true, good catch

ghost

LGTM !

ghost · 2026-04-14T11:20:50Z

 Ok(keys)
 	}

+	async fn list_paginated_internal(


It seems this is duplicating a lot of the logic of list_all_keys. Rather than doing that, can we
move the logic to a new method called list_keys or similar that takes the paget oken
move the while page_token != Some("".to_string()) loop to list_internal, calling list_keys
hence have both list_internal and list_internal_paginated reuse the same list_keys code to avoid duplication

Done, also fixed a potential issue where if the VSS server returned None for the page token we could go into an infinite loop.

ghost

Looks good I think, but I do wonder if we now need protocol-level versioning for VSS, see lightningdevkit/vss-server#96 (review).

ghost · 2026-04-20T12:48:52Z

 }
- Ok(keys)
+
+ Ok((keys, response.next_page_token))


list_keys returns response.next_page_token raw, so both callers independently handle the Some("") case. Would be cleaner to normalize it in list_keys itself. What do you think?

ghost · 2026-04-28T12:00:57Z

@benthecarman Any update here?

ghost

As mentioned above, I think we should wait to land this until we have the protocol versioning in VSS Server, so we can require it here (and error out if not met) before attempting to use pagination and fail at runtime.

ghost · 2026-05-06T01:25:57Z

🔔 1st Reminder

Hey @Camillarhi! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-05-09T00:00:52Z

🔔 2nd Reminder

Hey @Camillarhi! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-01T00:01:47Z

🔔 12th Reminder

Hey @Camillarhi! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-11T19:58:57Z

Rebased and updated vss-client to the 0.6

ghost

Mostly looks good, just some minor comments.

Please also include an entry in the compatibility section of the pending CHANGELOG.md to note that users must upgrade VSS server before upgrading LDK Node.

ghost · 2026-06-12T08:09:31Z

 native-tls = { version = "0.2", default-features = false, optional = true }
 postgres-native-tls = { version = "0.5", default-features = false, features = ["runtime"], optional = true }
-vss-client = { package = "vss-client-ng", version = "0.5" }
+vss-client = { package = "vss-client-ng", version = "0.6" }


Given this version introduced new error types (namely version mismatch, but can't recall if there are others), we'll need to update our retry policy to not retry if we hit a version mismatch, as it's unrecoverable.

Fixed. Looks like it would have failed before but now has better and more explicit error message

No, not what I meant: we need to update
fn retry_policy() -> CustomRetryPolicy{
above to skip_retry_on_error for VSSVersionMismatchError.

ghost · 2026-06-15T00:00:47Z

🔔 1st Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-15T00:00:59Z

🔔 1st Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Switches vss-client-ng to the crates.io 0.6 release. Generated with OpenAI Codex.

Move repeated VssStore construction logic into a shared build_vss_store() helper and have existing tests use it. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Extract the single-page VSS listing logic into a list_keys method that accepts page_token and page_size parameters. list_internal now drives the pagination loop itself, calling list_keys per page. This prepares for PaginatedKVStore support which will reuse list_keys for single-page queries. This also fixes a potential issue where if the VSS server returned None for the page token we could enter into an infinite loop. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

ghost · 2026-06-17T00:00:52Z

🔔 2nd Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-17T00:01:59Z

🔔 2nd Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost

LGTM a few nits/questions

ghost · 2026-06-17T00:21:32Z

- let mut keys = vec![];
+ secondary_namespace: &str, page_token: Option<String>, page_size: Option<i32>,
+	) -> io::Result<(Vec<String>, Option<String>)> {
 let key_prefix = self.build_obfuscated_prefix(primary_namespace, secondary_namespace);


We used to do this encryption once for the entire list, but now we do this once for every page. Encryption with chacha20 is fast so should be fine?

moved outside to be safe

ghost · 2026-06-17T00:23:35Z

+
+ const PAGE_SIZE: i32 = 50;
+
+ let vss_page_token = page_token.map(|t| t.to_string());


Thought we could do a into_inner instead of allocating a new string to copy a string, but realized this is gated behind the upstream API so should be fine for now.

ghost · 2026-06-18T08:10:06Z

Oh, seems cargo fmt didn't pass on this branch. Now fixed in #942. I miss CI.

benthecarman · 2026-04-01T21:26:32Z

Implement PaginatedKVStore and PaginatedKVStoreSync traits for VssStore, enabling paginated key listing via cursor-based pagination using PageToken.

At the moment VSS returns them in key order which is not ideal. We would need to add to the VSS server timestamps so they are returned in creation order. Ideally though after that change, it wouldn't require any changes on the client or in here because we have already hooked up the pagination. Curious on @tankyleo's thoughts here.

After this we'll have pagination for all the kv stores and can move forward with using it inside of ldk-node

ldk-reviews-bot · 2026-04-01T21:26:36Z

👋 Thanks for assigning @tankyleo as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

tnull

Ah, I had hoped that we could do this after lightningdevkit/rust-lightning#4323 lands, i.e., add it upstream directly. However, that PR seems to be delayed now as reviewer brought up more requirements, so probably need to go ahead here.

I'll let @tankyleo take a first look here and on the corresponding vss-server PR.

ldk-reviews-bot · 2026-04-04T00:00:49Z

🔔 1st Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-04-06T00:01:50Z

🔔 2nd Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

tankyleo · 2026-04-06T19:32:40Z

+ // VSS uses empty string to signal the last page
+ let next_page_token =
+ response.next_page_token.filter(|t| !t.is_empty()).map(PageToken::new);


Sounds to me like we should line-up the VSS API and the PaginatedKVStore API better, I raised a similar point in the VSS PR.
Right now a VSS could return a non-empty keys list, but signal "no more data to give" with a String::new() for the page token.
A consumer of PaginatedKVStore does another roundtrip, but the VSS did not expect any further roundtrips.

Yeah I feel like page_token: None should just be the signal that there is no more. That's what we do in the file system store and sqlite. Should fix that on the vss-server side but we can keep this is_empty check for safety.

Changed in lightningdevkit/vss-server#96 to do this

Yeah I feel like page_token: None should just be the signal that there is no more. That's what we do in the file system store and sqlite. Should fix that on the vss-server side but we can keep this is_empty check for safety.
I think we're following protobuf's/Google's best practices here. https://google.aip.dev/158 states:
Response messages for collections should define a string next_page_token field, providing the user with a page token that may be used to retrieve the next page.
The field containing pagination results should be the first field in the message and have a field number of 1. It should be a repeated field containing a list of resources constituting a single page of results.
If the end of the collection has been reached, the next_page_token field must be empty. This is the only way to communicate "end-of-collection" to users.
If the end of the collection has not been reached (or if the API can not determine in time), the API must provide a next_page_token.

tankyleo · 2026-04-06T19:39:05Z

+ match response.next_page_token {
+ Some(token) => page_token = Some(token),
+ None => break,
+ }


hmm here we determine whether we are done with pagination based on whether the page token is None, and not whether the list is empty. I guess just looking for clarification on the PaginatedKVStore API :)

Update to handle empty string

benthecarman · 2026-04-08T19:59:56Z

Okay updated to be compliant with the AIP 158 stuff

tankyleo · 2026-04-09T22:50:51Z

+ PaginatedKVStoreSync::list_paginated(&store, ns, sub, page_token).unwrap();
+ all_keys.extend(response.keys);
+ match response.next_page_token {
+ Some(token) if !token.as_str().is_empty() => page_token = Some(token),


Sounds to me here we should break only if the page token field is None, and not if the token is Some(""), otherwise, some details of the VSS API are leaking past the PaginatedKVStore API ?

ah true, good catch

ghost

LGTM !

ghost · 2026-04-14T11:20:50Z

 Ok(keys)
 	}

+	async fn list_paginated_internal(


It seems this is duplicating a lot of the logic of list_all_keys. Rather than doing that, can we
move the logic to a new method called list_keys or similar that takes the paget oken
move the while page_token != Some("".to_string()) loop to list_internal, calling list_keys
hence have both list_internal and list_internal_paginated reuse the same list_keys code to avoid duplication

Done, also fixed a potential issue where if the VSS server returned None for the page token we could go into an infinite loop.

ghost

Looks good I think, but I do wonder if we now need protocol-level versioning for VSS, see lightningdevkit/vss-server#96 (review).

ghost · 2026-04-20T12:48:52Z

 }
- Ok(keys)
+
+ Ok((keys, response.next_page_token))


list_keys returns response.next_page_token raw, so both callers independently handle the Some("") case. Would be cleaner to normalize it in list_keys itself. What do you think?

ghost · 2026-04-28T12:00:57Z

@benthecarman Any update here?

ghost

As mentioned above, I think we should wait to land this until we have the protocol versioning in VSS Server, so we can require it here (and error out if not met) before attempting to use pagination and fail at runtime.

ghost · 2026-05-06T01:25:57Z

🔔 1st Reminder

Hey @Camillarhi! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-05-09T00:00:52Z

🔔 2nd Reminder

Hey @Camillarhi! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-01T00:01:47Z

🔔 12th Reminder

Hey @Camillarhi! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-11T19:58:57Z

Rebased and updated vss-client to the 0.6

ghost

Mostly looks good, just some minor comments.

Please also include an entry in the compatibility section of the pending CHANGELOG.md to note that users must upgrade VSS server before upgrading LDK Node.

ghost · 2026-06-12T08:09:31Z

 native-tls = { version = "0.2", default-features = false, optional = true }
 postgres-native-tls = { version = "0.5", default-features = false, features = ["runtime"], optional = true }
-vss-client = { package = "vss-client-ng", version = "0.5" }
+vss-client = { package = "vss-client-ng", version = "0.6" }


Given this version introduced new error types (namely version mismatch, but can't recall if there are others), we'll need to update our retry policy to not retry if we hit a version mismatch, as it's unrecoverable.

Fixed. Looks like it would have failed before but now has better and more explicit error message

No, not what I meant: we need to update
fn retry_policy() -> CustomRetryPolicy{
above to skip_retry_on_error for VSSVersionMismatchError.

ghost · 2026-06-15T00:00:47Z

🔔 1st Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-15T00:00:59Z

🔔 1st Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Switches vss-client-ng to the crates.io 0.6 release. Generated with OpenAI Codex.

Move repeated VssStore construction logic into a shared build_vss_store() helper and have existing tests use it. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Extract the single-page VSS listing logic into a list_keys method that accepts page_token and page_size parameters. list_internal now drives the pagination loop itself, calling list_keys per page. This prepares for PaginatedKVStore support which will reuse list_keys for single-page queries. This also fixes a potential issue where if the VSS server returned None for the page token we could enter into an infinite loop. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

ghost · 2026-06-17T00:00:52Z

🔔 2nd Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost · 2026-06-17T00:01:59Z

🔔 2nd Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ghost

LGTM a few nits/questions

ghost · 2026-06-17T00:21:32Z

- let mut keys = vec![];
+ secondary_namespace: &str, page_token: Option<String>, page_size: Option<i32>,
+	) -> io::Result<(Vec<String>, Option<String>)> {
 let key_prefix = self.build_obfuscated_prefix(primary_namespace, secondary_namespace);


We used to do this encryption once for the entire list, but now we do this once for every page. Encryption with chacha20 is fast so should be fine?

moved outside to be safe

ghost · 2026-06-17T00:23:35Z

+
+ const PAGE_SIZE: i32 = 50;
+
+ let vss_page_token = page_token.map(|t| t.to_string());


Thought we could do a into_inner instead of allocating a new string to copy a string, but realized this is gated behind the upstream API so should be fine for now.

ghost · 2026-06-18T08:10:06Z

Oh, seems cargo fmt didn't pass on this branch. Now fixed in #942. I miss CI.

benthecarman requested review from tankyleo and tnull April 1, 2026 21:26

tnull reviewed Apr 2, 2026
View reviewed changes

benthecarman added this to Weekly Goals Apr 2, 2026

benthecarman self-assigned this Apr 2, 2026

tankyleo reviewed Apr 6, 2026
View reviewed changes

benthecarman force-pushed the paginated-vss branch from efc5fd4 to 9102fbfCompare April 8, 2026 19:59

tankyleo self-requested a review April 9, 2026 15:51

tankyleo reviewed Apr 9, 2026
View reviewed changes

benthecarman force-pushed the paginated-vss branch from 9102fbf to eff0243Compare April 9, 2026 23:54

benthecarman requested a review from tankyleo April 9, 2026 23:55

tankyleo reviewed Apr 11, 2026
View reviewed changes

tnull self-requested a review April 13, 2026 12:54

tnull reviewed Apr 14, 2026
View reviewed changes

benthecarman force-pushed the paginated-vss branch from eff0243 to d3f29b0Compare April 14, 2026 19:54

tnull reviewed Apr 16, 2026
View reviewed changes

Camillarhi reviewed Apr 20, 2026
View reviewed changes

benthecarman force-pushed the paginated-vss branch 2 times, most recently from 3e5fc71 to a8ce0c7Compare May 4, 2026 01:24

benthecarman requested review from Camillarhi and tnull May 4, 2026 01:24

tnull reviewed May 5, 2026
View reviewed changes

tnull removed the request for review from Camillarhi June 2, 2026 08:20

benthecarman force-pushed the paginated-vss branch from a8ce0c7 to fd809c2Compare June 11, 2026 19:57

benthecarman requested review from tankyleo and tnull June 11, 2026 20:01

tnull reviewed Jun 12, 2026
View reviewed changes

benthecarman force-pushed the paginated-vss branch 2 times, most recently from 608f607 to f51bf20Compare June 12, 2026 19:22

benthecarman requested a review from tnull June 12, 2026 19:23

benthecarmanand others added 3 commits June 15, 2026 14:22

Update vss-client to 0.6
df8bf27
Switches vss-client-ng to the crates.io 0.6 release. Generated with OpenAI Codex.

Extract build_vss_store test helper
5933155
Move repeated VssStore construction logic into a shared build_vss_store() helper and have existing tests use it. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

benthecarman force-pushed the paginated-vss branch from f51bf20 to 0eb1cc6Compare June 15, 2026 19:23

tankyleo reviewed Jun 17, 2026
View reviewed changes

Add PaginatedKVStore support to VssStore
5429331

benthecarman force-pushed the paginated-vss branch from 0eb1cc6 to 5429331Compare June 17, 2026 19:46

benthecarman requested a review from tankyleo June 17, 2026 19:46

tankyleo approved these changes Jun 17, 2026
View reviewed changes

tnull approved these changes Jun 18, 2026
View reviewed changes

tnull merged commit fb7738f into lightningdevkit:mainJun 18, 2026

github-project-automationBot moved this to Done in Weekly Goals Jun 18, 2026

tnull mentioned this pull request Jun 18, 2026
Run cargo +nightly fmt on main #942
Merged