When running `make lint` in a git worktree, the diff processor fails
with "no version control repository found" because the Docker container
only mounts the worktree directory, not the main git directory that the
worktree's .git file references.
This causes golangci-lint's `new-from-rev` filter to not work, resulting
in all ~32k existing lint issues being reported instead of only newly
introduced ones.
Fix by detecting when we're in a worktree (.git is a file, not a
directory) and mounting the main .git directory into the container so
revgrep can access the git history.
The PR severity classifier was failing for external contributors because
the claude-code-action checks that the actor has write permissions. Since
this workflow only reads PR metadata via the API and doesn't execute any
code from the PR (and has restricted tool permissions), it's safe to allow
any user to trigger classification.
When a PR originates from a fork, the PR branch doesn't exist in the
origin remote. This adds a step that uses `gh pr checkout` before
running the Claude action, which properly handles fork PRs by adding
the fork as a remote and fetching the branch from there.
Switch from pull_request to pull_request_target to allow the workflow
to run on PRs from forks. The pull_request trigger runs in the fork's
context which cannot access repository secrets.
This is safe because the workflow only reads PR metadata via the GitHub
API (changed files, labels) and doesn't checkout or execute any code
from the PR itself.
Add a GitHub Actions workflow that uses Claude Code to automatically
classify PRs by severity based on the files changed. This helps
reviewers prioritize and understand PR complexity at a glance.
The workflow:
- Triggers on PR open and synchronize events
- Uses Claude Code to analyze changed files against severity mapping
- Applies one of four severity labels (critical/high/medium/low)
- Posts a detailed comment explaining the classification
- Supports manual override via severity-override-* labels
Severity mapping:
- CRITICAL: lnwallet, htlcswitch, contractcourt, peer, keychain, input,
channeldb, funding, lnwire, server.go, rpcserver.go
- HIGH: routing, invoices, sweep, discovery, graph, watchtower, feature,
lnrpc, macaroons, chainntnfs, etc.
- MEDIUM: payments, autopilot, lncfg, kvdb, proto files, etc.
- LOW: docs, tests, scripts, CI/CD config
This increases the minimum CLTV delta allowed for invoice creation to
provide more headroom above DefaultFinalCltvRejectDelta (19 blocks).
The previous value of 18 was below the reject threshold, which could
allow users to create invoices with CLTV deltas that would be rejected
when receiving payments.
With this change, we'll go to chain even earlier to ensure that we have
enough time to sweep a potentially contested HTLC, now that we're
waiting longer before sweeps to ensure that the commitment transaction
is sufficeitnyl burried before we sweep.
In this commit, we add a fast-path optimization to the chain watcher's
closeObserver that immediately dispatches close events when only a single
confirmation is required (numConfs == 1). This addresses a timing issue
with integration tests that were designed around the old synchronous
blockbeat behavior, where close events were dispatched immediately upon
spend detection.
The recent async confirmation architecture (introduced in commit f6f716ab7)
properly handles reorgs by waiting for N confirmations before dispatching
close events. However, this created a race condition in integration tests
that mine blocks synchronously and expect immediate close notifications.
With the build tag setting numConfs to 1 for itests, the async confirmation
notification could arrive after the test already started waiting for the
close event, causing timeouts.
We introduce a new handleSpendDispatch method that checks if numConfs == 1
and, if so, immediately calls handleCommitSpend to dispatch the close event
synchronously, then returns true to skip the async state machine. This
preserves the old behavior for integration tests while maintaining the full
async reorg protection for production (where numConfs >= 3).
The implementation adds the fast-path check in both spend detection paths
(blockbeat and spend notification) to ensure consistent behavior regardless
of which detects the spend first. We also update the affected unit tests to
remove their expectation of confirmation registration, since the fast-path
bypasses that step entirely.
This approach optimizes for the integration test scenario without compromising
production safety, as the fast-path only activates when a single confirmation
is sufficient - a configuration that only exists in the controlled test
environment.
In this commit, we add a set of generic close re-org tests. The most
important test is the property based test, they will randomly confirm
transactions, generate a re-org, then assert that eventually we dtect
the final version.
This set of new tests ensures that if have created N RBF variants of the
coop close transaction, that any of then can confirm, and be re-org'd,
with us detecting the final spend once it confirms deeploy enough.
In this commit, we update the close logic to handle re-ogs up to the
final amount of confirmations. This is done generically, so we're able
to handle events such as: coop close confirm, re-org, breach confirm,
re-org, force close confirm, re-org, etc.
The upcoming set of new tests will exercise all of these cases.
We modify the block beat handling to unify the control flow. As it's
possible we get the beat, then see the spend, or the oher way around.
We wnt to add better handling, but not break any UIs or wallets. So
we'll continue to send out a notification after a single confirmation,
then send another after things are fully confirmed.
In this commit, we add a new param that'll allow us to scale up the
number of confirmations before we act on a new close. We'll use this
later to improve the current on chain handling logic.
Re-adds the old no-experimental-endorsement config option as a hidden,
deprecated alias for no-experimental-accountability. This ensures
backward compatibility for users who have the old option in their
config files after the rename it.
Add integration test to verify that fundMax uses the protocol-level
maximum channel size instead of the user-configured maxChanSize. The
test uses a table-driven approach to cover both non-wumbo and wumbo
scenarios, creating nodes with restrictive maxChanSize (5M sats) and
verifying that fundMax still creates channels at the protocol maximum.
The maxChanSize config option is documented to only apply to incoming
channel requests. However, when using fundMax with OpenChannel, the code
was incorrectly using maxChanSize as the upper bound for the outgoing
channel size.
This commit fixes the issue by using the protocol-level maximum
(MaxBtcFundingAmount or MaxBtcFundingAmountWumbo depending on wumbo
support) as the upper bound for fundMax operations.
Fixes#10468.
Gijs van Dam