Error during POST: 500 Internal Server Error #1742
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
5 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#1742
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?
Using tahoe from the 1.9.2 darcs branch on I2P, I received the following copying files to the grid [for formatting]edited:
Attachment incident-2012-05-17--19-17-46Z-kkjrsvq.flog.bz2 (75706 bytes) added
possibly relevant incident
Of course, retrying the put operation completed successfully.
Attachment active.png (40687 bytes) added
The top two operations failed over 12 hours ago
In the image below are four "active" operations:
:active.png
The top two failed around twelve hours earlier but remain in the list.
FWIW, I have not seen this with the released v1.9.2---yet.
I just got a report from a customer (TV of Sv) with a matching stack trace, using 1.9.2 [for formatting]edited:
Similar traceback at https://tahoe-lafs.org/pipermail/tahoe-dev/2012-April/007273.html, where it occurred in conjunction with #1670 (but that could be a coincidence).
Tv of Sv carefully and repeatdly confirmed, at my request, that after he gets this exception that the new child does exist in the directory! So this exception is somehow not preventing the directory from being updated!
He wrote:
At my request, Tv of Sv reproduced it with Tahoe-LAFS v1.10.0 gateway:
Work in progress at https://github.com/daira/tahoe-lafs/commits/1742-error-during-post.
In /tahoe-lafs/trac-2024-07-25/commit/e821c9e23dd286734e7ebf0fbd17fa1fa5f4ff31:
In /tahoe-lafs/trac-2024-07-25/commit/e821c9e23dd286734e7ebf0fbd17fa1fa5f4ff31:
In /tahoe-lafs/trac-2024-07-25/commit/705c47f9e92c4dfc010ccc124a8c814ebeabb197:
In /tahoe-lafs/trac-2024-07-25/commit/705c47f9e92c4dfc010ccc124a8c814ebeabb197:
Hmm, we seem to be getting a trac notification for each github branch that a patch is pushed to (the above patches were pushed to both master and 1742-error-during-post on the official repo), but the branch name shown by trac is always
/trunk
.[as #1970]filed
As shown by the test, the assertion was triggered when a version obtained by, e.g.
servermap.best_recoverable_version()
is used with a (different) new or updated servermap, created after shares of that version have been lost.Note that using the version obtained by calling
best_recoverable_version()
on the new/updated servermap would not trigger the assertion. This may explain why it triggered relatively rarely, or why it was coded as an assertion.Milestone renamed
renaming milestone
Moving open issues out of closed milestones.
Ticket retargeted after milestone closed