#3614 Can't view ticket [23782]
closed
General
2015-08-20
2012-01-18
No
https://sourceforge.net/apps/trac/sourceforge/ticket/23782
I tried at add a comment to this ticket and now it won't open ("We are unable to display the page you requested.")
https://sourceforge.net/p/spacefm/tickets/20/Please restore that ticket if possible. Other tickets still open normally.
If tickets are this volatile maybe you should provide a way to export them all as a group into a plain text file so I can save them regularly.
According to the RSS feed for that ticket tool, I think the part that's causing issues is [code]udisks --mount /dev/sdb1[/code]
No stacktrace found, it seems to time out. You can get at the data via the API:
Originally by: ignorantguru
This ticket there doesn't open either
http://sourceforge.net/p/spacefm/tickets/14/
Originally by: ignorantguru
Please delete ticket numbers 14 and 20 - they have been resubmitted but I am unable to remove them. Thanks.
[code]is an artifact reference and must be doing something weirdOriginally by: jpfle
I'm the one who created tickets http://sourceforge.net/p/spacefm/tickets/14/ and https://sourceforge.net/rest/p/spacefm/tickets/20/
About the report 14 (generating a 500 error when visiting it), the problem may be caused by a Markdown bug: I noticed that the Markdown parser of SourceForge doesn't seem to handle very well block-code containing lines that start with a dot, for example (each space is drawn with a hyphen):
----.hidden-file
Yes. About the report 20, it seems that the bug is related to the following line:
[code]udisks --mount /dev/sdb1[/code]
because I tried to add again this code in the new report #25, but the preview failed, and when I removed the tags:
udisks --mount /dev/sdb1
the preview was able to process.
Fix for the link to code is on allura js/3614. I replicated this on my sandbox by creating a project with a "code" mount point tool, deleting the tool, then linking to
[code]in a ticket. The fix was to make sure the app containing the linked artifact has not been deleted before linking to it.The issue with the dot is a pygments bug (https://bitbucket.org/birkenfeld/pygments-main/issue/618/typeerror-when-guessing-the-lexer-of-a) which is fixed in their repo, however not in the official release. I'm putting this in blocked state until discussing in chat tomorrow how we want to handle this.
Turns out there was already a package in the siteops package collection to fix the dot problem, we just needed to add it to requirements so it got used. To test, build a new sandbox and confirm a ticket with this text " .hidden-folder-1/" doesn't error. See previous comment for testing the other issue.
https://sourceforge.net/p/spacefm/tickets/20/ is still failing, but the other one is fixed.
I think the reason it's timing out is because the short link query was returning every possible match over all projects. Because "code" is a default tool for new projects, there were probably way too many results to handle in a reasonable amount of time. I changed the query to only look for matches in the projects we're looking for artifacts in. I wasn't able to cause the error on my sandbox because I didn't have enough projects on there, so this should go into "validation" to check this has really fixed it after the push.
Nice! I tested this by loading a prod dataset on my sandbox, then adding
[code]to a ticket comment. On dev I got a timeout, on js/3614, I did not. Setting to validation so we can confirm in prod. I think this might also fix [#3074].Related
Tickets:
#3074There's a test failure; we should add a test; we should always use a neighborhood_id in
Project.querylookupsI added the limit to neighborhood when I fixed the test failure.