I think this has come up a couple of times in the past, let me see if I can dig it up.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Apr 18 2016
Apr 17 2016
Actually, now that I think about it, the chunked representation overlays the underlying object storage system, so file.info by itself isn't enough - it needs to also extend file.querychunks.
Actually, now that I think about it, the chunked representation overlays the underlying object storage system, so file.info by itself isn't enough - it needs to also extend file.querychunks.
I think adding it to conduit is a good compromise; there's very little that's useful in the UI, and if anyone complains about something it should be easy enough to pin just using file.info. file.info already is very short anyway, so adding a fileHandle field should be relatively kosher, I think.
oh lovely, haha
Kicking this to the daemons should be like 20 lines of code, but we probably also need to flag the file as "queued for deletion" in the UI in the meantime and prevent you from interacting with it, which touches a few other interfaces, so this isn't completely trivial.
Apr 16 2016
Closing for lack of feedback. Specifically we'd need to know exactly how to reproduce this locally before attempting any fixes.
I suspect it's due to the replace status code. Specifically, if a specific path is removed + added, it shows as different than a modify. When this is then copied, it looks like SVN is showing this code for the new path of the file too. See /rSVNTEST8.
Turns out that because all spaces were archived, repositories did not get an space assigned to them, explaining the error. After I re-enabled S1, I saw a box for selecting the space appear.
Yeah we should fix that, for sure. Thanks for digging into this.
Ok, Whoops. I toyed with it a bit earlier and created a space, then had the balls to archive it. I unarchived it and everything starts working again: Repositories get shown again in the Diffusion menu, old broken repos stay broken, but new repos can be edited just fine.
Have you set up Spaces?
Forgot to add a piece of the log, this may help:
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr: [2016-04-16 19:52:16] EXCEPTION: (Exception) Transaction ("PHID-XACT-REPO-zsj42jcwxpqm2z5", of type "core:space") requires a handle ("") that it did not load. at [<phabricator>/src/applications/transactions/storage/PhabricatorApplicationTransaction.php:310]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr: arcanist(head=master, ref.master=737f5c0df976), phabricator(head=master, ref.master=dd1023e5a8f8), phutil(head=master, ref.master=1ea69b48e36d)
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr: #0 <#2> PhabricatorApplicationTransaction::getHandle(NULL) called at [<phabricator>/src/applications/transactions/storage/PhabricatorApplicationTransaction.php:335]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr: #1 <#2> PhabricatorApplicationTransaction::renderHandleLink(NULL) called at [<phabricator>/src/applications/transactions/storage/PhabricatorApplicationTransaction.php:806]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr: #2 <#2> PhabricatorApplicationTransaction::getTitle() called at [<phabricator>/src/applications/repository/storage/PhabricatorRepositoryTransaction.php:492]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr: #3 <#2> PhabricatorRepositoryTransaction::getTitle() called at [<phabricator>/src/applications/transactions/view/PhabricatorApplicationTransactionView.php:429]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr: #4 <#2> PhabricatorApplicationTransactionView::renderEvent(PhabricatorRepositoryTransaction, array) called at [<phabricator>/src/applications/transactions/view/PhabricatorApplicationTransactionView.php:173]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr: #5 <#2> PhabricatorApplicationTransactionView::buildEvents(boolean) called at [<phabricator>/src/applications/transactions/view/PhabricatorApplicationTransactionView.php:220]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr: #6 <#2> PhabricatorApplicationTransactionView::buildPHUITimelineView() called at [<phabricator>/src/applications/transactions/view/PhabricatorApplicationTransactionView.php:200]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr: #7 <#2> phutil_escape_html(array) called at [<phutil>/src/markup/render.php:157]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr: #8 <#2> phutil_escape_html(array) called at [<phutil>/src/markup/render.php:119]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr: #9 <#2> phutil_tag(string, array, array) called at [<phabricator>/src/view/phui/PHUITwoColumnView.php:167]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr: #10 <#2> PHUITwoColumnView::buildMainColumn() called at [<phabricator>/src/view/phui/PHUITwoColumnView.php:103]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr: #11 <#2> PHUITwoColumnView::getTagContent() called at [<phabricator>/src/view/AphrontTagView.php:152]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr: #12 <#2> AphrontTagView::render() called at [<phabricator>/src/view/AphrontView.php:222]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr: #13 <#2> AphrontView::producePhutilSafeHTML() called at [<phutil>/src/markup/render.php:133]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr: #14 <#2> phutil_escape_html(PHUITwoColumnView) called at [<phutil>/src/markup/render.php:189]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr: #15 <#2> phutil_implode_html(string, array) called at [<phabricator>/src/view/page/PhabricatorBarePageView.php:58]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr: #16 <#2> PhabricatorBarePageView::willRenderPage() called at [<phabricator>/src/view/page/PhabricatorStandardPageView.php:195]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr: #17 <#2> PhabricatorStandardPageView::willRenderPage() called at [<phabricator>/src/view/page/AphrontPageView.php:46]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr: #18 <#2> AphrontPageView::render() called at [<phabricator>/src/view/page/PhabricatorStandardPageView.php:841]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr: #19 <#2> PhabricatorStandardPageView::produceAphrontResponse() called at [<phabricator>/src/aphront/configuration/AphrontApplicationConfiguration.php:615]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr: #20 <#2> AphrontApplicationConfiguration::produceResponse(AphrontRequest, PhabricatorStandardPageView) called at [<phabricator>/src/aphront/configuration/AphrontApplicationConfiguration.php:246]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr: #21 <#2> AphrontApplicationConfiguration::processRequest(AphrontRequest, PhutilDeferredLog, AphrontPHPHTTPSink, MultimeterControl) called at [<phabricator>/src/aphront/configuration/AphrontApplicationConfiguration.php:149]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr: #22 <#2> AphrontApplicationConfiguration::runHTTPRequest(AphrontPHPHTTPSink) called at [<phabricator>/webroot/index.php:17]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr: #23 phlog(Exception) called at [<phabricator>/src/aphront/response/AphrontUnhandledExceptionResponse.php:20]
2016-04-16 19:52:16: (mod_fastcgi.c.2695) FastCGI-stderr: #24 AphrontUnhandledExceptionResponse::setException(Exception) called at [<phabricator>/webroot/index.php:21]This stuff pops up after requesting a broken repositories config page. Also, the fact that a repository first needs to have a commit inside is not of influence, as is the fact that the initial visibility should be "Administrators only". You don't even need to change the value. I'll edit the task to provide a simpler reproduction step.
Looks like this was caused because my upgrade didn't upgrade all the way to HEAD (for some unknown reason :S ).
Yea, so I think the path forward is to check the version of WS and to add some docs about it in the aphlict changes, and just the general updating guide.
- If /w/x/ exists and is titled "History of X", it would be nice if [[ x ]] generated a link with the text "History of X" instead of a link with the text "x". Today, you must do [[ x | History of X ]] to get the proper link text.
Just some cleanup today. New daemon console now shows which hosts daemons are running on:
Cool. Yeah, that all sounds good to me.
Yeah that was my plan; relative links on non-Phriction pages just won't get marked up.
(If the current page isn't a Phriction page, I guess just don't mark the thing up?)
That seems reasonable to me. I like using ./ to opt in to this and not making it the default.
Apr 15 2016
@epriestley Can I write and submit a patch for this?
From IRC, this may be an issue with older ws (0.7.1) except that I also have 0.7.1 locally. But we should possibly upgrade / recommend upgrading / something like that.
I also tried swapping the ".key" and ".crt" but that gave me the same error as using a bogus file.
Other stuff I tried:
I can't immediately reproduce this...
A terrible workaround is to reload the page before editing.
FWIW, I briefly attempted to fix this while fixing T9348 and gave up.
From IRC, the HTTPS server didn't even start up (no port in netstat). So my first guess is that there's some 'error' handler we need to install, and that should tell us what the issue is (bad SSL key / weird Node stuff / who knows what).
Thanks! Sorry I missed those, should be cleared up.
The foundation for this now exists, and core features like browsing user profiles, wiki pages, tasks, etc., appear to work properly in read-only mode.
This is probably fairly straightforward, but I'd like to see some evidence that installs would actually benefit from it before pursuing it.
Got it, thanks guys.