I'm going to retarget this to make the API more consistent.

We should probably change this API to always return array(), the "sometimes array, sometimes scalar" return value is pretty unintuitive. And any code which fixed this by adding (array) will just work.

I'm going to close this for now since there's no more upstream action available given that the issue either no longer reproduces or disabling APCu appears to fix it and be a reasonable workaround.

Yeah, I think this didn't crop up sooner through a combination of the cache and there being relatively few files with multiple @phutil-external-symbol tags.

We don't really use APCu for very much, so if you are able to isolate it as the issue (or are just suspicious, e.g. based on that launchpad bug looking pretty similar) it's probably OK to turn it off. I'd expect you to lose something like 5% performance with it off, not 50%+.

If you turn APCu back on, does it freeze up again?

I'm not immediately sure about the daemon confusion, although I suspect it's not likely to be a hint at the root issue. Caching for setup issues falls back to some pretty whacky shenanigans with APC/APCu disabled.

That's probably a webhook URI configured in feed.http-hooks (which may no longer be configured).

I don't see anything interesting in Multimeter, it just shows that the host doesn't see much traffic and that we probably need to update some package definitions.

Are you running APC (Config → Cache Status shows APC as the active "Data Cache")?

Also, can you show me what these pages look like?

GET /res/phabricator/86668b8e/rsrc/js/phui/rdar.js HTTP/1.1

This is a bug with how relative/object policies and inherited/indirect policies interact.

I'm going to close this for now since I don't plan to take any further action as the upstream; this appears to be an environmental issue (which we don't offer support for) rather than a scalability limitation (which we do).

I've just dumped this on the pile of arc patch-related bugs. Some of them are likely duplicates, possibly including this one, but I don't expect to dig through that pile until the next major iteration on arc, since at least some of them are likely not addressable without other changes. T11429 has a rough overview of upcoming plans.

• Try to come up with a way that - can do something dangerous when injected into a CSS rule.
  • See D7274#47131 for a template of how to attack this.
  • If you can come up with any attacks, don't implement this.
• Adjust the regular expression in PhabricatorMonospacedFontSetting::filterMonospacedCSSRule() to include -.
• Adjust the error text in PhabricatorMonospacedFontSetting->validateTransactionValue() to say "..., hyphens, ..." or similar.

I'm not entirely sure, but it seems plausible. We compute "Queue Utilization" as basically:

No, not updated yet.

Well, "trivial" might be a little ambitious.

Ah, thanks! That's a bug which we hadn't run into yet, but it's trivial to fix.

Okay. Can you run this command?

Oh, no, this is the right task. Your logs:

Someone has configured a bad Nuance source, so let's start by fixing that.

The reason we suggest @ as a delimiter is that you don't have to escape forward slashes if you use a delimiter other than /, so you get a more readable regexp.

I believe this is fine; I can't immediately come up with an attack using -.

Form (1) is expected to work, which is why we don't document a need for form (7): one is not expected to exist. If form (1) does not work, this is a bug with Herald itself, not with the Herald documentation.

Thanks for the report. This should be fixed in HEAD of master, and fixed in production some time in the next 24 hours when the docs regenerate.

Those changes add a fairly coarse disk-based cache here for use by the CLI. I expect it to shed ~95% of the load and make the admin tier stop glowing white-hot 24/7.

Follow PhabricatorSearchEngineExtension or similar.

(The second step is because some types of attachments work on multiple object types, and you could even conceivably write an "edge" attachment here that just works for anything and returns all edges, although I'm not confident that doing so isn't a major security problem.)

I think you've already written these, but the budget walkthrough is:

For the record, I strongly endorse autopatching unreviewed code onto live, armed, autonomous combat vehicles.

Internal attachment is definitely the shortest path. Whatever we end up with is likely to look very similar to the naive version, and you can keep your attachment running after we offer an "edges" attachment, so there shouldn't be any real transition cost.

This is basically a special case of T5873.

If you give a Phurl an "Alias", you can type ((thatalias)) in Remarkup to reference it. For example:

I added a note about this to T7338 for the longer term.

That should really have been in a day 1 "spend 10 minutes doing this stuff first" document, I started collecting this stuff in T11561.

Alternate/simpler test is "does /phurl/ work".

Also, are prototype applications enabled (phabricator.show-prototypes)? If not, Phurl won't actually be installed.

Ah, okay. I'm not immediately sure, then -- did you restart Apache / is /config/edit/phurl.short-uri/ picking up the change?

I suppose we could link to /config/module/site/, which has a list of all Sites, but it's probably not intuitively obvious from there what's going on. It's also possible in some future world to reach this screen without running Phabricator at all (T1806), although probably unlikely.

First screen is good.

I've updated both hosts and manually fixed D16464 to display the correct changes.

Yeah, I just neglected to push secure002 when I pushed secure001. I'll fix this shortly.

Oh, this looks like a smoking gun:

There's no changeset in the database, so this isn't just a weird permissions issue -- legitimately, no changeset was extracted.

bin/differential extract rPHU491ebc74d816dbe2fc8bbbbc992e8a14f8c613be also extracts the change correctly:

This might actually something more narrowly scoped since, e.g., D16468, D16469, and D16470 worked fine.

Ah, yeah. If you're using Apache with <VirtualHost /> directives, try something like this?

I think it's just adding implements PhabricatorApplicationTransactionInterface, then adding the methods for that.

Also to fix.

I think this is straightforward to fi.

Sorry, we don't offer help with third-party application development!

Probably not. Because it's a scalability issue this does get some amount of internal priority, but we have a large amount of external prioritized work in queue ahead of it (see Prioritized).

Not yet, but soon. New code should use project.edit.

T10423 was resolved indirectly (in connection with T11524) so we've sort of inched forward here.

Try using project.edit instead.

I'd like to sort out T9365 / T10635 (better aggregation and/or query options for unit/coverage data) first, since that likely impacts how we GC this data. Ideally, we'd leave an aggregated stub behind (e.g., pass/failure count) rather than nuking the data completely.