Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Node shutdown never calls api.Service.Close, so websocket clients get 1006 instead of 1001

Closed
  • Is something wrong?
#5,670 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

A pull request for this has already been merged.

  • #5671 by @martinconic — merged

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
72/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
go
Domain
api, backend

Research direction

Start in pkg/node/node.go and trace how Bee.Shutdown closes b.apiCloser; compare that shutdown path with the earlier wiring described in the issue. Read api.Service.Close() and the shutdown error handling, then check the websocket handlers in pkg/api/pss.go, pkg/api/gsoc.go and pkg/api/chunk_stream.go. Done means shutdown invokes the service close before the HTTP server closes, records any returned error, and websocket clients receive code 1001.

Written by the indexing model from the issue text.

Description

Summary

On node shutdown, pkg/node never calls api.Service.Close(). Websocket clients of /pss, /gsoc and /chunks/stream are dropped when the process exits and see close code 1006, instead of the 1001 Going Away the handlers are written to send.

Cause

Bee.Shutdown closes b.apiCloser, which is the http.Server:

b.apiServer = apiServer
b.apiCloser = apiServer   // pkg/node/node.go
...
tryClose(b.apiCloser, "api")

http.Server.Close and Shutdown do not track hijacked connections, so open websockets are left alone. api.Service.Close() is what closes s.quit and cancels s.bgCtx, and nothing calls it.

Before #4651 (52be59c61, "merge bee and debug APIs"), the node also set b.apiCloser = apiService, so api.Service.Close() ran on shutdown. That line was removed in #4651 and nothing replaced it.

Impact
  • The s.quit branches in pkg/api/pss.go, pkg/api/gsoc.go and pkg/api/chunk_stream.go never run in production, so the close frame and the clean handler exit are skipped.
  • s.bgCtx, which bounds GSOC cache writes (pkg/api/gsoc.go), is never canceled.
  • Tests call Service.Close() directly, so they pass while production takes a different path.

The process still exits and nothing hangs. Clients get an abnormal closure and no reason.

Reproduce
  1. Start a node and open a websocket, for example GET /chunks/stream with Sec-WebSocket-Protocol: swarm-chunk-stream (#5618), or /pss/subscribe/{topic}.
  2. Send SIGTERM to the node.
  3. The client sees 1006 (abnormal closure), not 1001, and the node log has no api shutting down line.

Observed on a Sepolia testnet full node built from #5618 (95b4acd0).

Suggested fix

Call apiService.Close() in Bee.Shutdown, before the http.Server is shut down. It closes s.quit and waits up to 1s for websocket handlers to finish, so streams get their 1001 and in-flight handlers exit. Its error (api shutting down with open websockets) should be appended to the shutdown errors like the other components.

Dominant language
Go
Stars
1.5k
Forks
390
Avg merge
2d 23h
Merged PRs (30d)
24

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ethersphere/bee

All issues in ethersphere/bee

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.