Optimize paginated payment listing queries by joostjager · Pull Request #240 · lightningdevkit/ldk-server

joostjager · 2026-07-03T08:19:07Z

This replaces the SQLite pagination index with one that matches the actual paginated store access pattern: namespace filters first, followed by creation_time DESC, key ASC for cursor ordering. The previous creation_time-only index did not fit these queries well and could scan unrelated namespaces or require extra sorting.

It also adds a required list_values paginated store method and implements it in SqliteStore with a single query returning keys and serialized values. ListPayments and ListForwardedPayments now decode those returned values directly, avoiding the previous page-level N+1 pattern where listing 100 items could require 101 SQLite queries.

Use a composite namespace/time/key index because paginated store queries first constrain primary_namespace and secondary_namespace, then page and order by creation_time DESC and key ASC. The prior creation_time-only index did not match that access pattern and could scan rows from unrelated namespaces or require extra sorting. Existing databases may retain idx_creation_time; this change only stops creating it for new databases and creates idx_paginated_kv_namespace_time_key instead.

Add a required list_values method to the paginated store abstraction and implement it in SqliteStore with a single query that returns each page of keys and serialized values. Keep the existing cursor predicate, ordering, and page-token behavior. Switch ListPayments and ListForwardedPayments to decode the returned values directly so each page avoids the per-key read loop.

ldk-reviews-bot · 2026-07-03T08:19:10Z

👋 I see @valentinewallace was un-assigned.
If you'd like another reviewer assignment, please click here.

tnull

We're about to drop the SQLite / local forwarded payment store from Server as we're close to finally add all parts to LDK Node. So I don't think it makes sense to make changes to it right now?

joostjager · 2026-07-03T08:44:55Z

Opened this PR because I still had the code lying around from an older analysis, but I wasn’t fully up to date with what had happened in ldk-node.

The main thing to distill from it is probably this question on ldk-node#959, if it hasn’t already been answered elsewhere: lightningdevkit/ldk-node#959 (comment)

One meta note: the split between ldk-node and ldk-server does make this kind of thing a bit harder to track from the ldk-server side.

tnull · 2026-07-03T08:48:57Z

One meta note: the split between ldk-node and ldk-server does make this kind of thing a bit harder to track from the ldk-server side.

Yes, well, that split is exactly what we're trying to reduce currently, i.e., move any remaining custom 'logic' into Node so that Server is really just responsible for the API, dealing with the daemon etc.

joostjager · 2026-07-03T09:37:43Z

Once ldk-server is cleaned up again and this stateful logic has moved into ldk-node, I think it would be good to define the boundary strictly so we avoid future work and rework like this.

And I still think keeping this split across two repos introduces unnecessary visibility and change friction, but you all know my stance on that.

joostjager · 2026-07-03T08:19:07Z

This replaces the SQLite pagination index with one that matches the actual paginated store access pattern: namespace filters first, followed by creation_time DESC, key ASC for cursor ordering. The previous creation_time-only index did not fit these queries well and could scan unrelated namespaces or require extra sorting.

It also adds a required list_values paginated store method and implements it in SqliteStore with a single query returning keys and serialized values. ListPayments and ListForwardedPayments now decode those returned values directly, avoiding the previous page-level N+1 pattern where listing 100 items could require 101 SQLite queries.

Use a composite namespace/time/key index because paginated store queries first constrain primary_namespace and secondary_namespace, then page and order by creation_time DESC and key ASC. The prior creation_time-only index did not match that access pattern and could scan rows from unrelated namespaces or require extra sorting. Existing databases may retain idx_creation_time; this change only stops creating it for new databases and creates idx_paginated_kv_namespace_time_key instead.

Add a required list_values method to the paginated store abstraction and implement it in SqliteStore with a single query that returns each page of keys and serialized values. Keep the existing cursor predicate, ordering, and page-token behavior. Switch ListPayments and ListForwardedPayments to decode the returned values directly so each page avoids the per-key read loop.

ldk-reviews-bot · 2026-07-03T08:19:10Z

👋 I see @valentinewallace was un-assigned.
If you'd like another reviewer assignment, please click here.

tnull

We're about to drop the SQLite / local forwarded payment store from Server as we're close to finally add all parts to LDK Node. So I don't think it makes sense to make changes to it right now?

joostjager · 2026-07-03T08:44:55Z

Opened this PR because I still had the code lying around from an older analysis, but I wasn’t fully up to date with what had happened in ldk-node.

The main thing to distill from it is probably this question on ldk-node#959, if it hasn’t already been answered elsewhere: lightningdevkit/ldk-node#959 (comment)

One meta note: the split between ldk-node and ldk-server does make this kind of thing a bit harder to track from the ldk-server side.

tnull · 2026-07-03T08:48:57Z

One meta note: the split between ldk-node and ldk-server does make this kind of thing a bit harder to track from the ldk-server side.

Yes, well, that split is exactly what we're trying to reduce currently, i.e., move any remaining custom 'logic' into Node so that Server is really just responsible for the API, dealing with the daemon etc.

joostjager · 2026-07-03T09:37:43Z

Once ldk-server is cleaned up again and this stateful logic has moved into ldk-node, I think it would be good to define the boundary strictly so we avoid future work and rework like this.

And I still think keeping this split across two repos introduces unnecessary visibility and change friction, but you all know my stance on that.

joostjager · 2026-07-03T08:19:07Z

This replaces the SQLite pagination index with one that matches the actual paginated store access pattern: namespace filters first, followed by creation_time DESC, key ASC for cursor ordering. The previous creation_time-only index did not fit these queries well and could scan unrelated namespaces or require extra sorting.

It also adds a required list_values paginated store method and implements it in SqliteStore with a single query returning keys and serialized values. ListPayments and ListForwardedPayments now decode those returned values directly, avoiding the previous page-level N+1 pattern where listing 100 items could require 101 SQLite queries.

Use a composite namespace/time/key index because paginated store queries first constrain primary_namespace and secondary_namespace, then page and order by creation_time DESC and key ASC. The prior creation_time-only index did not match that access pattern and could scan rows from unrelated namespaces or require extra sorting. Existing databases may retain idx_creation_time; this change only stops creating it for new databases and creates idx_paginated_kv_namespace_time_key instead.

Add a required list_values method to the paginated store abstraction and implement it in SqliteStore with a single query that returns each page of keys and serialized values. Keep the existing cursor predicate, ordering, and page-token behavior. Switch ListPayments and ListForwardedPayments to decode the returned values directly so each page avoids the per-key read loop.

ldk-reviews-bot · 2026-07-03T08:19:10Z

👋 I see @valentinewallace was un-assigned.
If you'd like another reviewer assignment, please click here.

tnull

We're about to drop the SQLite / local forwarded payment store from Server as we're close to finally add all parts to LDK Node. So I don't think it makes sense to make changes to it right now?

joostjager · 2026-07-03T08:44:55Z

Opened this PR because I still had the code lying around from an older analysis, but I wasn’t fully up to date with what had happened in ldk-node.

The main thing to distill from it is probably this question on ldk-node#959, if it hasn’t already been answered elsewhere: lightningdevkit/ldk-node#959 (comment)

One meta note: the split between ldk-node and ldk-server does make this kind of thing a bit harder to track from the ldk-server side.

tnull · 2026-07-03T08:48:57Z

One meta note: the split between ldk-node and ldk-server does make this kind of thing a bit harder to track from the ldk-server side.

Yes, well, that split is exactly what we're trying to reduce currently, i.e., move any remaining custom 'logic' into Node so that Server is really just responsible for the API, dealing with the daemon etc.

joostjager · 2026-07-03T09:37:43Z

Once ldk-server is cleaned up again and this stateful logic has moved into ldk-node, I think it would be good to define the boundary strictly so we avoid future work and rework like this.

And I still think keeping this split across two repos introduces unnecessary visibility and change friction, but you all know my stance on that.

joostjager · 2026-07-03T08:19:07Z

This replaces the SQLite pagination index with one that matches the actual paginated store access pattern: namespace filters first, followed by creation_time DESC, key ASC for cursor ordering. The previous creation_time-only index did not fit these queries well and could scan unrelated namespaces or require extra sorting.

It also adds a required list_values paginated store method and implements it in SqliteStore with a single query returning keys and serialized values. ListPayments and ListForwardedPayments now decode those returned values directly, avoiding the previous page-level N+1 pattern where listing 100 items could require 101 SQLite queries.

Use a composite namespace/time/key index because paginated store queries first constrain primary_namespace and secondary_namespace, then page and order by creation_time DESC and key ASC. The prior creation_time-only index did not match that access pattern and could scan rows from unrelated namespaces or require extra sorting. Existing databases may retain idx_creation_time; this change only stops creating it for new databases and creates idx_paginated_kv_namespace_time_key instead.

Add a required list_values method to the paginated store abstraction and implement it in SqliteStore with a single query that returns each page of keys and serialized values. Keep the existing cursor predicate, ordering, and page-token behavior. Switch ListPayments and ListForwardedPayments to decode the returned values directly so each page avoids the per-key read loop.

ldk-reviews-bot · 2026-07-03T08:19:10Z

👋 I see @valentinewallace was un-assigned.
If you'd like another reviewer assignment, please click here.

tnull

We're about to drop the SQLite / local forwarded payment store from Server as we're close to finally add all parts to LDK Node. So I don't think it makes sense to make changes to it right now?

joostjager · 2026-07-03T08:44:55Z

Opened this PR because I still had the code lying around from an older analysis, but I wasn’t fully up to date with what had happened in ldk-node.

The main thing to distill from it is probably this question on ldk-node#959, if it hasn’t already been answered elsewhere: lightningdevkit/ldk-node#959 (comment)

One meta note: the split between ldk-node and ldk-server does make this kind of thing a bit harder to track from the ldk-server side.

tnull · 2026-07-03T08:48:57Z

One meta note: the split between ldk-node and ldk-server does make this kind of thing a bit harder to track from the ldk-server side.

Yes, well, that split is exactly what we're trying to reduce currently, i.e., move any remaining custom 'logic' into Node so that Server is really just responsible for the API, dealing with the daemon etc.

joostjager · 2026-07-03T09:37:43Z

Once ldk-server is cleaned up again and this stateful logic has moved into ldk-node, I think it would be good to define the boundary strictly so we avoid future work and rework like this.

And I still think keeping this split across two repos introduces unnecessary visibility and change friction, but you all know my stance on that.

joostjager · 2026-07-03T08:19:07Z

This replaces the SQLite pagination index with one that matches the actual paginated store access pattern: namespace filters first, followed by creation_time DESC, key ASC for cursor ordering. The previous creation_time-only index did not fit these queries well and could scan unrelated namespaces or require extra sorting.

It also adds a required list_values paginated store method and implements it in SqliteStore with a single query returning keys and serialized values. ListPayments and ListForwardedPayments now decode those returned values directly, avoiding the previous page-level N+1 pattern where listing 100 items could require 101 SQLite queries.

Use a composite namespace/time/key index because paginated store queries first constrain primary_namespace and secondary_namespace, then page and order by creation_time DESC and key ASC. The prior creation_time-only index did not match that access pattern and could scan rows from unrelated namespaces or require extra sorting. Existing databases may retain idx_creation_time; this change only stops creating it for new databases and creates idx_paginated_kv_namespace_time_key instead.

Add a required list_values method to the paginated store abstraction and implement it in SqliteStore with a single query that returns each page of keys and serialized values. Keep the existing cursor predicate, ordering, and page-token behavior. Switch ListPayments and ListForwardedPayments to decode the returned values directly so each page avoids the per-key read loop.

ldk-reviews-bot · 2026-07-03T08:19:10Z

👋 I see @valentinewallace was un-assigned.
If you'd like another reviewer assignment, please click here.

tnull

We're about to drop the SQLite / local forwarded payment store from Server as we're close to finally add all parts to LDK Node. So I don't think it makes sense to make changes to it right now?

joostjager · 2026-07-03T08:44:55Z

Opened this PR because I still had the code lying around from an older analysis, but I wasn’t fully up to date with what had happened in ldk-node.

The main thing to distill from it is probably this question on ldk-node#959, if it hasn’t already been answered elsewhere: lightningdevkit/ldk-node#959 (comment)

One meta note: the split between ldk-node and ldk-server does make this kind of thing a bit harder to track from the ldk-server side.

tnull · 2026-07-03T08:48:57Z

One meta note: the split between ldk-node and ldk-server does make this kind of thing a bit harder to track from the ldk-server side.

Yes, well, that split is exactly what we're trying to reduce currently, i.e., move any remaining custom 'logic' into Node so that Server is really just responsible for the API, dealing with the daemon etc.

joostjager · 2026-07-03T09:37:43Z

Once ldk-server is cleaned up again and this stateful logic has moved into ldk-node, I think it would be good to define the boundary strictly so we avoid future work and rework like this.

And I still think keeping this split across two repos introduces unnecessary visibility and change friction, but you all know my stance on that.

joostjager · 2026-07-03T08:19:07Z

This replaces the SQLite pagination index with one that matches the actual paginated store access pattern: namespace filters first, followed by creation_time DESC, key ASC for cursor ordering. The previous creation_time-only index did not fit these queries well and could scan unrelated namespaces or require extra sorting.

It also adds a required list_values paginated store method and implements it in SqliteStore with a single query returning keys and serialized values. ListPayments and ListForwardedPayments now decode those returned values directly, avoiding the previous page-level N+1 pattern where listing 100 items could require 101 SQLite queries.

Use a composite namespace/time/key index because paginated store queries first constrain primary_namespace and secondary_namespace, then page and order by creation_time DESC and key ASC. The prior creation_time-only index did not match that access pattern and could scan rows from unrelated namespaces or require extra sorting. Existing databases may retain idx_creation_time; this change only stops creating it for new databases and creates idx_paginated_kv_namespace_time_key instead.

Add a required list_values method to the paginated store abstraction and implement it in SqliteStore with a single query that returns each page of keys and serialized values. Keep the existing cursor predicate, ordering, and page-token behavior. Switch ListPayments and ListForwardedPayments to decode the returned values directly so each page avoids the per-key read loop.

ldk-reviews-bot · 2026-07-03T08:19:10Z

👋 I see @valentinewallace was un-assigned.
If you'd like another reviewer assignment, please click here.

tnull

We're about to drop the SQLite / local forwarded payment store from Server as we're close to finally add all parts to LDK Node. So I don't think it makes sense to make changes to it right now?

joostjager · 2026-07-03T08:44:55Z

Opened this PR because I still had the code lying around from an older analysis, but I wasn’t fully up to date with what had happened in ldk-node.

The main thing to distill from it is probably this question on ldk-node#959, if it hasn’t already been answered elsewhere: lightningdevkit/ldk-node#959 (comment)

One meta note: the split between ldk-node and ldk-server does make this kind of thing a bit harder to track from the ldk-server side.

tnull · 2026-07-03T08:48:57Z

One meta note: the split between ldk-node and ldk-server does make this kind of thing a bit harder to track from the ldk-server side.

Yes, well, that split is exactly what we're trying to reduce currently, i.e., move any remaining custom 'logic' into Node so that Server is really just responsible for the API, dealing with the daemon etc.

joostjager · 2026-07-03T09:37:43Z

Once ldk-server is cleaned up again and this stateful logic has moved into ldk-node, I think it would be good to define the boundary strictly so we avoid future work and rework like this.

And I still think keeping this split across two repos introduces unnecessary visibility and change friction, but you all know my stance on that.

joostjager · 2026-07-03T08:19:07Z

This replaces the SQLite pagination index with one that matches the actual paginated store access pattern: namespace filters first, followed by creation_time DESC, key ASC for cursor ordering. The previous creation_time-only index did not fit these queries well and could scan unrelated namespaces or require extra sorting.

It also adds a required list_values paginated store method and implements it in SqliteStore with a single query returning keys and serialized values. ListPayments and ListForwardedPayments now decode those returned values directly, avoiding the previous page-level N+1 pattern where listing 100 items could require 101 SQLite queries.

Use a composite namespace/time/key index because paginated store queries first constrain primary_namespace and secondary_namespace, then page and order by creation_time DESC and key ASC. The prior creation_time-only index did not match that access pattern and could scan rows from unrelated namespaces or require extra sorting. Existing databases may retain idx_creation_time; this change only stops creating it for new databases and creates idx_paginated_kv_namespace_time_key instead.

Add a required list_values method to the paginated store abstraction and implement it in SqliteStore with a single query that returns each page of keys and serialized values. Keep the existing cursor predicate, ordering, and page-token behavior. Switch ListPayments and ListForwardedPayments to decode the returned values directly so each page avoids the per-key read loop.

ldk-reviews-bot · 2026-07-03T08:19:10Z

👋 I see @valentinewallace was un-assigned.
If you'd like another reviewer assignment, please click here.

tnull

We're about to drop the SQLite / local forwarded payment store from Server as we're close to finally add all parts to LDK Node. So I don't think it makes sense to make changes to it right now?

joostjager · 2026-07-03T08:44:55Z

Opened this PR because I still had the code lying around from an older analysis, but I wasn’t fully up to date with what had happened in ldk-node.

The main thing to distill from it is probably this question on ldk-node#959, if it hasn’t already been answered elsewhere: lightningdevkit/ldk-node#959 (comment)

One meta note: the split between ldk-node and ldk-server does make this kind of thing a bit harder to track from the ldk-server side.

tnull · 2026-07-03T08:48:57Z

One meta note: the split between ldk-node and ldk-server does make this kind of thing a bit harder to track from the ldk-server side.

Yes, well, that split is exactly what we're trying to reduce currently, i.e., move any remaining custom 'logic' into Node so that Server is really just responsible for the API, dealing with the daemon etc.

joostjager · 2026-07-03T09:37:43Z

Once ldk-server is cleaned up again and this stateful logic has moved into ldk-node, I think it would be good to define the boundary strictly so we avoid future work and rework like this.

And I still think keeping this split across two repos introduces unnecessary visibility and change friction, but you all know my stance on that.

joostjager · 2026-07-03T08:19:07Z

This replaces the SQLite pagination index with one that matches the actual paginated store access pattern: namespace filters first, followed by creation_time DESC, key ASC for cursor ordering. The previous creation_time-only index did not fit these queries well and could scan unrelated namespaces or require extra sorting.

It also adds a required list_values paginated store method and implements it in SqliteStore with a single query returning keys and serialized values. ListPayments and ListForwardedPayments now decode those returned values directly, avoiding the previous page-level N+1 pattern where listing 100 items could require 101 SQLite queries.

Use a composite namespace/time/key index because paginated store queries first constrain primary_namespace and secondary_namespace, then page and order by creation_time DESC and key ASC. The prior creation_time-only index did not match that access pattern and could scan rows from unrelated namespaces or require extra sorting. Existing databases may retain idx_creation_time; this change only stops creating it for new databases and creates idx_paginated_kv_namespace_time_key instead.

Add a required list_values method to the paginated store abstraction and implement it in SqliteStore with a single query that returns each page of keys and serialized values. Keep the existing cursor predicate, ordering, and page-token behavior. Switch ListPayments and ListForwardedPayments to decode the returned values directly so each page avoids the per-key read loop.

ldk-reviews-bot · 2026-07-03T08:19:10Z

👋 I see @valentinewallace was un-assigned.
If you'd like another reviewer assignment, please click here.

tnull

We're about to drop the SQLite / local forwarded payment store from Server as we're close to finally add all parts to LDK Node. So I don't think it makes sense to make changes to it right now?

joostjager · 2026-07-03T08:44:55Z

Opened this PR because I still had the code lying around from an older analysis, but I wasn’t fully up to date with what had happened in ldk-node.

The main thing to distill from it is probably this question on ldk-node#959, if it hasn’t already been answered elsewhere: lightningdevkit/ldk-node#959 (comment)

One meta note: the split between ldk-node and ldk-server does make this kind of thing a bit harder to track from the ldk-server side.

tnull · 2026-07-03T08:48:57Z

One meta note: the split between ldk-node and ldk-server does make this kind of thing a bit harder to track from the ldk-server side.

Yes, well, that split is exactly what we're trying to reduce currently, i.e., move any remaining custom 'logic' into Node so that Server is really just responsible for the API, dealing with the daemon etc.

joostjager · 2026-07-03T09:37:43Z

Once ldk-server is cleaned up again and this stateful logic has moved into ldk-node, I think it would be good to define the boundary strictly so we avoid future work and rework like this.

And I still think keeping this split across two repos introduces unnecessary visibility and change friction, but you all know my stance on that.

joostjager added 2 commits July 3, 2026 10:15

tnull reviewed Jul 3, 2026
View reviewed changes

ldk-reviews-bot requested a review from valentinewallace July 3, 2026 08:29

tnull removed the request for review from valentinewallace July 3, 2026 08:29

joostjager closed this Jul 3, 2026

joostjager mentioned this pull request Jul 21, 2026
Stop keeping the full payment history in memory lightningdevkit/ldk-node#998
Closed

joostjager added 2 commits July 3, 2026 10:15

tnull reviewed Jul 3, 2026
View reviewed changes

ldk-reviews-bot requested a review from valentinewallace July 3, 2026 08:29

tnull removed the request for review from valentinewallace July 3, 2026 08:29

joostjager closed this Jul 3, 2026

joostjager mentioned this pull request Jul 21, 2026
Stop keeping the full payment history in memory lightningdevkit/ldk-node#998
Closed

joostjager added 2 commits July 3, 2026 10:15

tnull reviewed Jul 3, 2026
View reviewed changes

ldk-reviews-bot requested a review from valentinewallace July 3, 2026 08:29

tnull removed the request for review from valentinewallace July 3, 2026 08:29

joostjager closed this Jul 3, 2026

joostjager mentioned this pull request Jul 21, 2026
Stop keeping the full payment history in memory lightningdevkit/ldk-node#998
Closed

joostjager added 2 commits July 3, 2026 10:15

tnull reviewed Jul 3, 2026
View reviewed changes

ldk-reviews-bot requested a review from valentinewallace July 3, 2026 08:29

tnull removed the request for review from valentinewallace July 3, 2026 08:29

joostjager closed this Jul 3, 2026

joostjager mentioned this pull request Jul 21, 2026
Stop keeping the full payment history in memory lightningdevkit/ldk-node#998
Closed

joostjager added 2 commits July 3, 2026 10:15

tnull reviewed Jul 3, 2026
View reviewed changes

ldk-reviews-bot requested a review from valentinewallace July 3, 2026 08:29

tnull removed the request for review from valentinewallace July 3, 2026 08:29

joostjager closed this Jul 3, 2026

joostjager mentioned this pull request Jul 21, 2026
Stop keeping the full payment history in memory lightningdevkit/ldk-node#998
Closed

joostjager added 2 commits July 3, 2026 10:15

tnull reviewed Jul 3, 2026
View reviewed changes

ldk-reviews-bot requested a review from valentinewallace July 3, 2026 08:29

tnull removed the request for review from valentinewallace July 3, 2026 08:29

joostjager closed this Jul 3, 2026

joostjager mentioned this pull request Jul 21, 2026
Stop keeping the full payment history in memory lightningdevkit/ldk-node#998
Closed

joostjager added 2 commits July 3, 2026 10:15

tnull reviewed Jul 3, 2026
View reviewed changes

ldk-reviews-bot requested a review from valentinewallace July 3, 2026 08:29

tnull removed the request for review from valentinewallace July 3, 2026 08:29

joostjager closed this Jul 3, 2026

joostjager mentioned this pull request Jul 21, 2026
Stop keeping the full payment history in memory lightningdevkit/ldk-node#998
Closed

joostjager added 2 commits July 3, 2026 10:15

tnull reviewed Jul 3, 2026
View reviewed changes

ldk-reviews-bot requested a review from valentinewallace July 3, 2026 08:29

tnull removed the request for review from valentinewallace July 3, 2026 08:29

joostjager closed this Jul 3, 2026

joostjager mentioned this pull request Jul 21, 2026
Stop keeping the full payment history in memory lightningdevkit/ldk-node#998
Closed

Uh oh!

Conversation

joostjager commented Jul 3, 2026

Uh oh!

ldk-reviews-bot commented Jul 3, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

joostjager commented Jul 3, 2026

Uh oh!

tnull commented Jul 3, 2026

Uh oh!

joostjager commented Jul 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

joostjager commented Jul 3, 2026

Uh oh!

ldk-reviews-bot commented Jul 3, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

joostjager commented Jul 3, 2026

Uh oh!

tnull commented Jul 3, 2026

Uh oh!

joostjager commented Jul 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

joostjager commented Jul 3, 2026

Uh oh!

ldk-reviews-bot commented Jul 3, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

joostjager commented Jul 3, 2026

Uh oh!

tnull commented Jul 3, 2026

Uh oh!

joostjager commented Jul 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

joostjager commented Jul 3, 2026

Uh oh!

ldk-reviews-bot commented Jul 3, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tnull left a comment

ldk-reviews-bot commented Jul 3, 2026•
edited
Loading

ldk-reviews-bot commented Jul 3, 2026•
edited
Loading

ldk-reviews-bot commented Jul 3, 2026•
edited
Loading

ldk-reviews-bot commented Jul 3, 2026•
edited
Loading

ldk-reviews-bot commented Jul 3, 2026•
edited
Loading