clarify error message when upload fails due to insufficient servers of happiness #834
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
2 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#834
Loading…
Reference in New Issue
Block a user
No description provided.
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?
allmydata.com user gar5 reported:
Hopefully Kevan can think of a better way to express this situation and he can add it to his patch for #778. Maybe saying the number of queries which resulted in "I'm full so I can't hold your share" would help. Something like:
Hm.
I agree that that message is confusing. I like your error message, too, and I think that it would fix the immediate problem.
Do you think that
NotEnoughSharesError
is informative enough, given the new behavior? I'm on the fence.It seemed a lot easier to say
NotEnoughSharesError
and have it be meaningful with theshares_of_happiness
behavior. In that case, you'd only raise the error if you failed to place enough shares on the grid. Now,NotEnoughSharesError
can be raised not only for that, but becauseservers_of_happiness
isn't satisfied, which doesn't immediately spring to my mind when I readNotEnoughSharesError
. Maybe we could make something likeUnhappyGridError
-- something that gets raised where we raiseNotEnoughSharesError
in the peer selection process and elsewhere, where appropriate, when our upload is unsuccessful becauseservers_of_happiness
isn't satisfied. This avoids overloading the meaning of the exception in other cases where it is used -- i.e., when downloading.I'll start working on the message part of this ticket, though.
Okay, so I'm updating the patches for #778 with a few things related to this ticket:
UploadHappinessError
, which is raised in place ofNotEnoughSharesError
andNoSharesError
during the upload process. (the latter two exceptions are still raised on downloads)Any thoughts?
This issue is now tracked by #778.