- User Since
- Dec 10 2014, 3:16 PM (222 w, 6 d)
Mar 17 2018
For what it's worth, after spot-checking a few tasks on my install, all seem to query the same policy 10ish times in succession near the end of the load.
Not sure if it's expected in the current state, but here's one that doesn't seem well-formed: https://secure.phabricator.com/fact/chart/?y1=tasks.open-count.status
Dec 21 2017
Nov 23 2017
I'm unable to close this, but I believe this to be resolved (or at least my specific repro of flags via herald no longer applies I believe).
Obviously not a particularly important issue, but this now will populate a link in the favorites menu which leads to an exception:
For completeness's sake, this sounds like the issue that hit me in T9025 where the charts accumulated task counts greater than the number of open tasks (and indeed, the counts in a maniphest search by project now seem to pretty closely match the end state of the corresponding chart).
Jul 10 2017
Jun 3 2017
Slightest of issues with the repository indexing mentioned above:
luca:~/phabricator$ ./bin/search index --type repository --force Usage Exception: Type "repository" matches multiple indexable objects. Use a more specific string. Matching object types are: PhabricatorRepository, PhabricatorRepositoryCommit. luca:~/phabricator$
I had an interesting experience with this where I purportedly reclaimed negative space (and none of it via the worker schema). Happy to past more from the probe if people are interested:
luca:~/phabriactors$ ./bin/storage probe ... phabricator_worker 160.0 MB 1.5% edgedata 0.0 MB 0.0% lisk_counter 0.0 MB 0.0% worker_triggerevent 0.0 MB 0.0% worker_trigger 0.0 MB 0.0% edge 0.0 MB 0.0% worker_activetask 0.1 MB 0.0% worker_bulkjob 0.3 MB 0.0% worker_bulkjobtransaction 0.4 MB 0.0% worker_bulktask 0.8 MB 0.0% worker_archivetask 48.1 MB 0.4% worker_taskdata 110.1 MB 1.0% ... TOTAL 10,839.3 MB 100.0% luca:~/phabriactors$ ./bin/storage optimize ... OPTIMIZE Optimizing table "phabricator_differential"."differential_transaction_comment"... DONE Compacted table by 1 MB in 5,834ms. OPTIMIZE Optimizing table "phabricator_feed"."feed_storyreference"... DONE Compacted table by 3 MB in 49,097ms. OPTIMIZE Optimizing table "phabricator_search"."search_documentfield"... DONE Compacted table by 43 MB in 97,513ms. ... OPTIMIZE Optimizing table "phabricator_worker"."edge"... DONE Optimized table (in 11ms) but it had little effect. OPTIMIZE Optimizing table "phabricator_worker"."edgedata"... DONE Optimized table (in 9ms) but it had little effect. OPTIMIZE Optimizing table "phabricator_worker"."lisk_counter"... DONE Optimized table (in 10ms) but it had little effect. OPTIMIZE Optimizing table "phabricator_worker"."worker_activetask"... DONE Optimized table (in 18ms) but it had little effect. OPTIMIZE Optimizing table "phabricator_worker"."worker_archivetask"... DONE Optimized table (in 3,703ms) but it had little effect. OPTIMIZE Optimizing table "phabricator_worker"."worker_bulkjob"... DONE Optimized table (in 61ms) but it had little effect. OPTIMIZE Optimizing table "phabricator_worker"."worker_bulkjobtransaction"... DONE Optimized table (in 45ms) but it had little effect. OPTIMIZE Optimizing table "phabricator_worker"."worker_bulktask"... DONE Optimized table (in 117ms) but it had little effect. OPTIMIZE Optimizing table "phabricator_worker"."worker_taskdata"... DONE Optimized table (in 4,186ms) but it had little effect. OPTIMIZE Optimizing table "phabricator_worker"."worker_trigger"... DONE Optimized table (in 12ms) but it had little effect. OPTIMIZE Optimizing table "phabricator_worker"."worker_triggerevent"... DONE Optimized table (in 10ms) but it had little effect. ... OPTIMIZED Completed optimizations, reclaimed -4 GB of disk space.` luca:~/phabriactors$ ./bin/storage probe ... phabricator_worker 144.0 MB 1.4% edgedata 0.0 MB 0.0% lisk_counter 0.0 MB 0.0% worker_triggerevent 0.0 MB 0.0% worker_trigger 0.0 MB 0.0% edge 0.0 MB 0.0% worker_activetask 0.1 MB 0.0% worker_bulkjob 0.3 MB 0.0% worker_bulkjobtransaction 0.4 MB 0.0% worker_bulktask 0.8 MB 0.0% worker_archivetask 32.6 MB 0.3% worker_taskdata 109.5 MB 1.1% ... TOTAL 10,105.5 MB 100.0%
May 29 2017
I had indeed implemented precisely that herald rule once I realized that these diffs were being created without repository info attached. I also added repository.callsign to /etc/arcconfig to eliminate the problem going forward.
Apr 20 2017
Mar 8 2017
Jan 28 2017
More or less ran into first issue with Q444.
Jan 13 2017
I don't think this is quite the same issue, but seems related, so I thought I'd err on the side of not creating a dupe.
Jan 12 2017
Jan 8 2017
(And again, to emphasize, I'm happy to drop this if y'all aren't interested. I have my solution and am happy ignoring this, but just thought it might be something you guys would want to check out.)
Head as of my Dec. 17 post in this thread. Can roll forward, but was hoping to wait till the edit engine migration settled a bit.
@epriestley any suggestions?
Jan 7 2017
I did some further digging and made a little progress
Dec 17 2016
Thanks for the advice. That yields the trace below. My understanding is that it was a diff with policy set to subscribers which had an author plus a single subscriber. That subscriber was added by herald upon the diff's creation, so there's certainly grounds for something going on there. I had trouble divining the exact issue, but tinkering with the permissions for the object ended up letting the emails go through.
Just updated to head and am seeing the same issues.
Dec 10 2016
Nov 26 2016
Aug 24 2016
Aug 8 2016
it's just likely very complex when we have to save an entire object state ... instead of approximately a single blob of text
Understood. For me personally, the single blob text would be more than sufficient. I don't mind repopulating everything else (assignment, subscribers, tags, customs, etc.) as those usually require much less thought and drafting.
Aug 7 2016
Jul 28 2016
No biggie, although the UI effect is obviously crucial for my org
Jul 23 2016
Jul 18 2016
Jun 29 2016
FWIW, the answer to both of your questions before you edited it was yes :p
Thanks for such a quick response!
Jun 28 2016
I'm not sure what to do with your link. Here's what I can reproduce:
Apr 23 2016
Well now I feel silly for not noticing that. I searched for the line number of the error ><
Apr 18 2016
Apr 16 2016
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.
Apr 1 2016
Doesn't seem specific to php.
Mar 22 2016
Mar 21 2016
Indeed. Sounds like I just need T5873 then. Thanks.
Feb 11 2016
I would take great delight in using such a tool
Feb 10 2016
Yeah, I think the end vision as in your mockup looks pretty nifty. Maybe part of the issue is that the photo thumbs feel kind of chunky in the workboard right now.
FWIW, the second issue listed here is biting me too a bit on my install.
Jan 12 2016
Oh, it sounded like the path forward was T3967, so I was unsure what people were complaining about given that things seemed fine to me, but that task was still open.
Nov 24 2015
Confirming that removing the apostrophe from the slug in the db did resolve. Thanks.
I did indeed update across those 3 revisions you listed; I was previously at October 11.
I think I see the issue.
I too cannot recreate it.
Nov 23 2015
That matches what I found as well (although I'm sure trivial means different things to each of us :p). Abandoning in favor of T3353
Oct 21 2015
Bummer. Thanks though.
Oct 20 2015
Yeah. gotcha. At risk of suggestion solutions and vs. describing problems, certainly the way I think about it is:
- What is the common prefix of all these file changes (i.e. /repo/projects/tfb/www/trunk/main/production/master/) aka where in the tree did I invoke arc diff?
- What are the sub-paths w.r.t. the prefix of each file changed (i.e. path/to/file.c)?
Oct 19 2015
Seems like that didn't quite get it yet (see D14301). Below is my transcript:
Ahh, looks like not. We'd been slowly phasing out .arcconfigs since the removal or arcanist projects.
Oct 18 2015
Hmmm, I didn't actually move any files. Maybe this is a derivate of the issue in T9188 then?
Oct 16 2015
Oct 7 2015
On the other hand, there were observable effects in the similar case of T7284
Sep 17 2015
Sep 14 2015
Sep 11 2015
Just noting that I use it in almost exactly the same way (although the audits show on my default dashboard rather than me manually going into the audit application).
Sep 10 2015
You listed T7783 twice above btw. Was one of those instances supposed to be a different task?
Sep 7 2015
I think this is T8800
I believe this occurred to me with Q120.
Sep 4 2015
Aug 21 2015
Aug 19 2015
Aug 18 2015
I'm gonna say this is moot now that arcanist project aren't a thing anymore.
Just to spitball...
Aug 15 2015
Thanks for fixing things up there.
Aug 14 2015
Ahh, interesting. Yes, I did.
Aug 7 2015
I was feeling particularly creative today