add regression test for shnums: "e,r,r,o,r" #1171
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#1171
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?
In this download status page that I attached to #1170 -- http://tahoe-lafs.org/trac/tahoe-lafs/attachment/ticket/1170/down-1.html one of the entries in the "shnums" column (the one for serverid 62nlabgf), says
e,r,r,o,r
.Perhaps we should investigate and make sure that this doesn't cause worse problems, and fix it in 1.8.0 if it is easy to fix or if it causes worse problems.
I agree with checking that it doesn't cause worse problems, but I have a for-after-1.8.0 patch to rewrite the way that errors are recorded in the
DownloadStatus
structure that will make this go away.This is another bug that was introduced in v1.8.0 and it would be great if we could fix it in v1.8.1, but someone would have to volunteer to do the work quite soon.
warner: can your patch mentioned in comment:79640 be applied for 1.10 without disruption?
I'll investigate.. this one might alredy be fixed now.
It looks like the changes I had in mind have been applied already. Specifically, source:src/allmydata/immutable/downloader/status.py#L42
DYHBEvent
has a distincterror()
method, and source:src/allmydata/immutable/downloader/finder.py calls exactly one offinished()
orerror()
. Soshnums
should only ever be a list of share numbers (keys of the dict-of-buckets returned by a successful DYHB call).So I'm closing this one.
I briefly looked at the two links into the source code that Brian posted in comment:79649 and it looks good to me.
This didn't have a test though. Ideally we should have a regression test.
shnums: "e,r,r,o,r"to add regression test for shnums: "e,r,r,o,r"