`firebase_admin.db.reference` leaks connections in a `CLOSE_WAIT` state

Bắt đầu bằng cách tái hiện vấn đề với một máy chủ websocket Python, tạo một firebase_admin.db.reference và gọi set trong trình xử lý kết nối. Sử dụng netstat sau khi các kết nối kết thúc để kiểm tra các socket CLOSE_WAIT. Hoàn tất khi vòng đời của kết nối reference được giải thích và tình trạng tích tụ được báo cáo đã được giải quyết hoặc hành vi teardown cần thiết đã được ghi lại.

Step 2: Describe your environment

• Operating System version: OS X Ventura 13.4
• Firebase SDK version: 6.2.0
• Firebase Product: database
• Python version: 3.11.2
• Pip version: 23.1.2

Step 3: Describe the problem

I have a Python websocket application that creates a reference to RTDB via firebase_admin.db.reference, and writes to it via the set method. I create one reference per connection to my database. It appears that this reference does not necessarily get cleaned up, as I've noticed in my server that connections with a CLOSE_WAIT state are aggregating specifically with this RTDB update. More concerning is that the application appears to be receiving bytes of data at a consistent rate from this connection despite it being in a CLOSE_WAIT state.

What is the proper way to tear down a reference once I know I'm done with it? It seems like this is a bug from the firebase_admin python package as there don't be any instructions or indication that we need to tear down the reference.

Steps to reproduce:

1. Create a Python websocket server with the websockets library
2. Within the connection handler, instantiate a reference via firebase_admin.db.reference and write a value
3. Approximately 1 minute after the connection terminates, use netstat to observe that the connection still exists in a CLOSE_WAIT state and that the application is receiving data from it.

Here's my netstat output

root@474683837e04:/app# netstat -ntuap
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.11:38913        0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      1/python
tcp       25      0 172.24.0.3:34160        34.120.160.131:443      CLOSE_WAIT  1/python
tcp        1      0 172.24.0.3:58576        142.250.191.74:443      CLOSE_WAIT  1/python
tcp6       0      0 :::8080                 :::*                    LISTEN      1/python
udp        0      0 127.0.0.11:54888        0.0.0.0:*                           -

Using connections with all of the reference related code commented out and then netstat'ing after shows that this issue does not appeare.