Oh, I guess there isn't actually a "test plan" Herald field. We could add one easily enough. I was thinking:

Settings → Email Preferences → Self Actions

I suspect this has never worked and it isn't trivial to fix. D14168 is just some nearby code cleanup that I did while I was looking at it.

What status code do you feel is more appropriate? 403 seems quite reasonable to me.

You don't actually care about download/view (i.e., the Content-Disposition of the response), you just want a URL which shows the current contents, right?

Prior to, e.g., T8921, we were very lax about lint messages which led to a lot of linters passing nonsense (e.g., non-numeric line numbers, negative character offsets, human-readable durations with units like "3 seconds"). Formalization of lint in connection with T8089 implicitly increased strictness.

See:

ehh

No clue how to repro. I'll accept a diff to get the rule ID/PHID into the error message if you want.

I don't currently plan to try to let fields be configured per-repository. This would be a lot of work to accommodate a fairly rare need, require substantial workflow changes, and doesn't seem to be particularly valuable. Workarounds like the one above (or just writing similar Herald rules) seem reasonable to me, if not ideal.

I can't reproduce this on any of the systems I have access to (although none are replicas of your system) and, in general, there is nothing Phabricator should be able to do in PHP to cause a process to segfault (except maybe willfully sending ourselves signals). With very rare exception, segfaults are caused by PHP itself or an extension, not by us. I also haven't seen other reports of anything similar.

I think it's probably correct for task titles, Phriction document titles, etc., to not be Remarkup.

I'm just going to merge this into T3278 since I think that covers this completely.

Actually, I can't immediately reproduce this. Here's what I did to set the test up:

For HTTP stuff which doesn't return a response (like this), the best debugging tool is sometimes using phlog(), then tail -f on the apache/php-fpm error log in another window.

This is obsolete at HEAD.

Modern arc should catch this on the client instead.

(We maintain a vulnerability program with HackerOne, but this specific issue is pretty fluff and in a prototype application so I don't think it meets the minimum bar for a vulnerability award ("significantly compromise ... typical installation"). Feel free to file through HackerOne if you hit anything security-esque and more substantive in the future, though.)

Thanks for the report! This should be resolved in HEAD and deployed to this server.

This is functional locally and headed for production after T7399 resolves enough to let us do build tier deployments without leaking live key material.

• I've separated key material from rSAAS and cycled the key. It was always ephemeral, but now it is managed in a more standard way.
• I've separated all API key material from rCORE, but not cycled it. There were a couple more keys than I found earlier (ReCaptcha, SES + S3 for this host).

It might become possible after T731, but this is a very rare need and not a good fit for the upstream except as part of more general changes in T731.

I'm going to work on separating the rSAAS key material and remaining rCORE key material now.

A likely fix for this is now available in HEAD:

Oh, I'm wrong. It is idempotent, so we should be OK.

(This migration isn't idempotent and I can't really test it thoroughly since we don't have year-old environments on hand, so there's going to be some level of guesswork here.)

I'll relax this migration, give me a few minutes. You have some sketchy data in your transaction history but we can just ignore it safely.

D14144 is tangential here but gives resources and leases a meaningful destruction phase.

I think everything is setting ownerPHID now.

So my question is, how would you like us to communicate the issues we encounter, if at all, specifically concerning Drydock/Harbormaster from now on and in the future?

Drydock is a prototype, see:

Drydock is a prototype, see:

Drydock is a prototype, see:

More broadly, we're now much of the way toward a functional v1 here but most of the interesting action has been attached to T9253 rather than directly to this task, and getting this operating in the upstream has depended on Phacility changes in T7399 (I don't want any live Phacility credentials to exist on the build hosts in any form, but do want to deploy them using common cluster tooling).

Cool, glad things are working again.

The queue has flushed so I think this is now resolved (there are no longer any publish actions backed up in the queue), can you let me know if you're still seeing issues when you have a chance?

I've deployed this to repo001 (where this instance's daemons are located) and the queue appears to be flushing. I'd expect that you'll start receiving missing mail shortly (there are about 100 affected commits in the backlog). I'll follow up in a few minutes once things flush or otherwise stabilize.