[needs test] Capability of interrupted downloads is logged in twistd.log #685
Labels
No Label
0.2.0
0.3.0
0.4.0
0.5.0
0.5.1
0.6.0
0.6.1
0.7.0
0.8.0
0.9.0
1.0.0
1.1.0
1.10.0
1.10.1
1.10.2
1.10a2
1.11.0
1.12.0
1.12.1
1.13.0
1.14.0
1.15.0
1.15.1
1.2.0
1.3.0
1.4.1
1.5.0
1.6.0
1.6.1
1.7.0
1.7.1
1.7β
1.8.0
1.8.1
1.8.2
1.8.3
1.8β
1.9.0
1.9.0-s3branch
1.9.0a1
1.9.0a2
1.9.0b1
1.9.1
1.9.2
1.9.2a1
LeastAuthority.com automation
blocker
cannot reproduce
cloud-branch
code
code-dirnodes
code-encoding
code-frontend
code-frontend-cli
code-frontend-ftp-sftp
code-frontend-magic-folder
code-frontend-web
code-mutable
code-network
code-nodeadmin
code-peerselection
code-storage
contrib
critical
defect
dev-infrastructure
documentation
duplicate
enhancement
fixed
invalid
major
minor
n/a
normal
operational
packaging
somebody else's problem
supercritical
task
trivial
unknown
was already fixed
website
wontfix
worksforme
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#685
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
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?
I happened to see this in the twisted.log of a Tahoe-1.3.0 node (the testgrid web gateway):
As far as I can tell, the register/unregister producer code in source:src/allmydata/immutable/download.py hasn't changed since before the v1.3.0 release, so I suspect this bug is still here in trunk. I assume that it doesn't cause any actual trouble beyond noise in the
twistd.log
... Or does it? Maybe it wastes some memory? I guess the next step is to find this error message in the Twisted code base (Twisted v2.5.0 was used here).This is part of a cluster of tickets including: #562, #563, #685, #887, #1008, and #1904.
is this happening when somebody is downloading the file and stops their browser before the download has completed?
I suspect that I added that exception, since I used to be in the habit of raising
RuntimeError
as a sort of assertion. I suspect that the only consequences of this problem would be that we'd keep the tahoe-side download going even though nobody's left on the HTTP side to receive the data. But it might also mean that I don't understand producers and consumers (and twisted.web) as well as I thought I did.(similar code is used in the FTP and SFTP servers, so we should make sure we know what sort of access was being used for that particular operation)
The fact that this leads to caps and filenames being written into
twistd.log
is a privacy and confidentiality issue: #887 (twisted.web logs the uri on some exceptional conditions, leading to a privacy leak in logfiles)This looks like it's coming from Twisted directly, rather than from something which I wrote: twisted/web/http.py Request._cleanup (about line 591).
Not sure why this was priority 'minor'.
#1155 was a duplicate.
Here's the
Request._cleanup
method in Twisted 10.1.0. I can't immediately see how to fix this, short of replacing the logging sink and filtering strings containing "URI:
" in all log messages.RuntimeError: Producer was not unregisteredto Capability of interrupted downloads is logged in twistd.logThis should be fixed in changeset:4b7c94ece074ede2, pushed a few hours after the release of 1.8.0b2 . The fix is to make sure we call
unregisterProducer
in all cases, even when the connection is dropped (which calls ourstopProducing
method). At least, this stops the log message in my experiments.We need a test for this, that would have failed before changeset:4b7c94ece074ede2.
not making it into 1.9
Capability of interrupted downloads is logged in twistd.logto [needs test] Capability of interrupted downloads is logged in twistd.log#887 was a duplicate of this.