github-starred/pangolin
2
0
Fork 0
mirror of https://github.com/fosrl/pangolin.git synced 2026-07-16 06:08:33 -05:00
Code Issues 1.6k Packages Projects Releases 79 Wiki Activity

[PR #3069] [CLOSED] Return error response for stale hole-punch rejection #25769

New Issue
Closed
opened 2026-06-07 20:23:16 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-06-07 20:23:16 -05:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/fosrl/pangolin/pull/3069
Author: @rinseaid
Created: 5/14/2026
Status: ❌ Closed

Base: dev ← Head: fix/stale-holepunch-error-response-v2

📝 Commits (1)

  • 8c7ac9c Return error response for stale hole-punch rejection during Olm registration

📊 Changes

2 files changed (+6 additions, -1 deletions)

View changed files

📝 server/routers/olm/error.ts (+5 -0)
📝 server/routers/olm/handleOlmRegisterMessage.ts (+1 -1)

📄 Description

Community Contribution License Agreement

By creating this pull request, I grant the project maintainers an unlimited,
perpetual license to use, modify, and redistribute these contributions under any terms they
choose, including both the AGPLv3 and the Fossorial Commercial license terms. I
represent that I have the right to grant this license for all contributed content.

Preface

This PR was developed with Claude Code (claude-opus-4-6). I identified the bug through live debugging of a broken Olm tunnel after a Pangolin server restart, traced the root cause through the code, and directed the fix. Claude wrote the patch. I reviewed and validated all changes.

Description

When handleOlmRegisterMessage rejects a registration because lastHolePunch is stale (more than 5 seconds old and the client has sites to receive), it performs a bare return with no response to the client. The client has no way to know its registration was rejected or why, so it retries blindly until it exhausts its retry budget (20 attempts at 2-second intervals), then gives up silently.

This is particularly problematic during server restarts: the server's in-memory lastHolePunch timestamps reset, so the first registration attempt after reconnect is always rejected. Combined with the Olm re-registration bug (fosrl/olm#123), this creates a double failure where the client either never re-registers or re-registers into a silent rejection loop.

Fix: Send an olm/error response with a new STALE_HOLE_PUNCH error code before returning. This uses the existing sendOlmError pattern that other rejection paths in the same function already use. The Olm client's handleOlmError handler will log the error and surface it via the API server status endpoint, giving users visibility into the failure.

Related issues: #2951, #2901, #2318, #2343, #3041, #1526

Companion PR: fosrl/olm#123

How to test?

  1. Connect an Olm client with at least one site configured.
  2. Restart the Pangolin server.
  3. Watch Olm client logs after reconnect.
  4. Before fix: Client retries registration 20 times with no feedback, then silently gives up. Server logs warn about stale hole punch but client sees nothing.
  5. After fix: Client receives STALE_HOLE_PUNCH error and logs it. The error is visible in the Olm status API.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/fosrl/pangolin/pull/3069 **Author:** [@rinseaid](https://github.com/rinseaid) **Created:** 5/14/2026 **Status:** ❌ Closed **Base:** `dev` ← **Head:** `fix/stale-holepunch-error-response-v2` --- ### 📝 Commits (1) - [`8c7ac9c`](https://github.com/fosrl/pangolin/commit/8c7ac9c23d9074a86a7856cb05bbf56a1c495c63) Return error response for stale hole-punch rejection during Olm registration ### 📊 Changes **2 files changed** (+6 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `server/routers/olm/error.ts` (+5 -0) 📝 `server/routers/olm/handleOlmRegisterMessage.ts` (+1 -1) </details> ### 📄 Description ## Community Contribution License Agreement By creating this pull request, I grant the project maintainers an unlimited, perpetual license to use, modify, and redistribute these contributions under any terms they choose, including both the AGPLv3 and the Fossorial Commercial license terms. I represent that I have the right to grant this license for all contributed content. ### Preface This PR was developed with Claude Code (claude-opus-4-6). I identified the bug through live debugging of a broken Olm tunnel after a Pangolin server restart, traced the root cause through the code, and directed the fix. Claude wrote the patch. I reviewed and validated all changes. ## Description When `handleOlmRegisterMessage` rejects a registration because `lastHolePunch` is stale (more than 5 seconds old and the client has sites to receive), it performs a bare `return` with no response to the client. The client has no way to know its registration was rejected or why, so it retries blindly until it exhausts its retry budget (20 attempts at 2-second intervals), then gives up silently. This is particularly problematic during server restarts: the server's in-memory `lastHolePunch` timestamps reset, so the first registration attempt after reconnect is always rejected. Combined with the Olm re-registration bug (fosrl/olm#123), this creates a double failure where the client either never re-registers or re-registers into a silent rejection loop. **Fix:** Send an `olm/error` response with a new `STALE_HOLE_PUNCH` error code before returning. This uses the existing `sendOlmError` pattern that other rejection paths in the same function already use. The Olm client's `handleOlmError` handler will log the error and surface it via the API server status endpoint, giving users visibility into the failure. Related issues: #2951, #2901, #2318, #2343, #3041, #1526 Companion PR: fosrl/olm#123 ## How to test? 1. Connect an Olm client with at least one site configured. 2. Restart the Pangolin server. 3. Watch Olm client logs after reconnect. 4. **Before fix:** Client retries registration 20 times with no feedback, then silently gives up. Server logs warn about stale hole punch but client sees nothing. 5. **After fix:** Client receives `STALE_HOLE_PUNCH` error and logs it. The error is visible in the Olm status API. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
GiteaMirror added the pull-request label 2026-06-07 20:23:16 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
api
authentication
bug
config
dependencies
docker
documentation
enhancement
good first issue
help wanted
Improvement
Look Into
needs investigating
networking
new feature
non-critical bug
potential bug
pull-request
Mirrored from GitHub Pull Request
 question
reverse proxy
Security
stale
ui
wontfix
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/pangolin#25769
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?