Release 2.3.2#1076
Conversation
test: add probeNode devtools command
feat: add resetScores devtools command
* feat: show probe route fee * fix: tune scorer fee params * fix: address probe compile errors * fix: use scorer defaults
Greptile SummaryThis PR prepares the 2.3.2 release and updates Lightning probing behavior. The main changes are:
Confidence Score: 4/5The changed score reset flow can leave the Lightning node stopped after a successful delete and failed restart.
app/src/main/java/to/bitkit/repositories/LightningRepo.kt
|
| Filename | Overview |
|---|---|
| gradle/libs.versions.toml | Bumps ldk-node-android from rc.46 to rc.52, which carries the new probing and scoring API surface used by the app. |
| app/src/main/java/to/bitkit/services/LightningService.kt | Adds custom scoring fee parameters and applies them during LDK node builder setup. |
| app/src/main/java/to/bitkit/repositories/LightningRepo.kt | Adds route-fee data to probe outcomes, score-sync timestamp readiness data, and a devtools-facing pathfinding score reset flow. |
| app/src/debug/java/to/bitkit/dev/DevToolsProvider.kt | Adds debug commands for node probing and pathfinding score resets. |
| app/src/main/java/to/bitkit/viewmodels/ProbingToolViewModel.kt | Uses probe outcome route fees for the probing result model while keeping the existing capacity check flow. |
| app/src/main/java/to/bitkit/ui/screens/settings/ProbingToolScreen.kt | Displays route fees in msat in the probing tool result UI. |
Reviews (1): Last reviewed commit: "chore: version 2.3.2" | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| val resetAtSecs = nowMillis() / 1000 | ||
|
|
There was a problem hiding this comment.
When both VSS deletes succeed but the final start(walletIndex = walletIndex, shouldRetry = false) fails, this function returns that failure after the score objects have already been removed and the node is still stopped. The debug reset command only reports an error in that path, so a reset during a transient startup failure can leave the app without a running Lightning node until another restart path runs.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 596eb6c7de
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| graphNodeCount = graph?.nodeCount, | ||
| graphChannelCount = graph?.channelCount, | ||
| latestRgsSyncTimestamp = graph?.latestRgsSyncTimestamp, | ||
| latestPathfindingScoresSyncTimestamp = state.nodeStatus?.latestPathfindingScoresSyncTimestamp, |
There was a problem hiding this comment.
When resetScores restarts the node, LDK merges the external scores in its background scorer; if that completes after the last syncState() call during startup, _lightningState.nodeStatus still contains the old/null timestamp. Callers polling probeReadiness can then keep seeing stale latestPathfindingScoresSyncTimestamp even though lightningService.status has advanced, making the reset/e2e verification time out until some unrelated state refresh occurs.
Useful? React with 👍 / 👎.
| return@withContext Result.failure(it) | ||
| } | ||
|
|
||
| val resetAtSecs = nowMillis() / 1000 |
There was a problem hiding this comment.
This returns the reset marker truncated to epoch seconds immediately before restarting the node. Because latestPathfindingScoresSyncTimestamp is also reported in whole seconds, a successful external-score merge that happens in the same second will equal this marker; any caller following the comment's strict-newer check will treat the reset as not refreshed, making the devtools/e2e flow flaky. Use a marker from before the delete/start boundary or make the comparison inclusive.
Useful? React with 👍 / 👎.
|
Re-Running from dispatch against release-2.3.2 branch: https://github.com/synonymdev/bitkit-android/actions/runs/29349079016/job/87140403130 The failures here are mostly caused by the fact that CI uses the workflow from the merge preview (release-2.3.2 into master), not from release-2.3.2 alone and there were changes to the e2e workflow in the meantime (e.g. hardware shard added) which spills into here as well. |
|
Dispatch passed: https://github.com/synonymdev/bitkit-android/actions/runs/29349079016/job/87142127256 |
2 participants
The purpose of this PR is only to run the e2e suite.