still won't get cleaned up and instead Drydock will just fail to allocate.

So you have a machine full of unused working copies, and Drydock is failing every build instead of reusing them?

When this happens, there'll be hundreds of builds all running at the same time, which can result in hundreds of working copies for the same repository.

I'm concerned that it's difficult to give users a descriptive error message if the pattern is an arbitrary regular expression. What does your patch do when a filename fails a custom regular expression? Specifically, how does it help the user fix their filename?

I don't know how to reproduce the behavior this report describes. See Contributing Bug Reports.

I can't reproduce this. Here's what I did:

Aaah! That makes sense.

I'm not 100% sure it actually works, but you'd just do this:

I believe if you include a transaction which sets the CCs to the current CCs, it is guaranteed to run after any personal rules and will entirely undo the effects of any sneaky rules anyone might write.

We also probably need to implement Phabricator Credits before we can add ᵐᶦᶜʳᵒᵖᵃʸᵐᵉᶰᵗˢ because otherwise we'll just be paying Stripe for the privilege of having ᵐᶦᶜʳᵒᵖᵃʸᵐᵉᶰᵗˢ.

My major concern with pursuing that (or, say, "$1 to file a task") is that user expectations will be like billion times higher if something costs $0.25 than if it's free.

I think that'll fix it, let us know if you're still seeing issues? Thanks for the report!

This is from D14622, probably just a missed grep (likely because the method name is spelled QuickSand instead of Quicksand at this callsite).

Broadly, we're in no rush to get rid of these events -- definitely no need to panic. I just wanted to push things in the right direction after T9851 was filed, which originally asked for the scope of these events to be substantially expanded.

My recollection, at least, is that Herald wasn't originally suitable because of T6367. Prior to that task, an "attacker" could write a rule like this:

See prior discussion in T5021 / D9270.

What are you doing which can't be covered by Herald?

I can't reproduce this. Here's what I did:

That's expected if you've written an "every time" rule.

so I end up with lots of copies of the same thing

Which instructions were you looking at which you found confusing? Can you point me at the document? (Or was it the setup warning itself?)

Aliased 'arc foo' to 'foo'.

There's no description of what problems this is trying to solve. I don't want to just add random fields in the hope that some will be useful; see Contributing Feature Requests.

I'll need to at some point go and clean these up.

• I believe username association works correctly.
• Assigning an email is already mandatory when creating a bot:

I don't plan Almanac to ever autoscale. Autoscaling would be via a new, non-Almanac EC2 blueprint (or similar blueprints, which permit creation of new host resources). I'm just going to merge this into T5544.

Perfect! This should be easy to fix.

I can reproduce the bug on what I think is a relatively up-to-date production installation.

You need to give us steps we can actually follow in a development environment to reproduce the issue. We can not examine database data, logs, etc, on the WMF install.

Here's what I get. Note:

I can't reproduce, those steps work fine for me on this install. I can click "Show Details" on the transaction above while logged out and get a dialog showing the details.

Here's my guess at how to reproduce:

This is very unlikely to happen.

D14589 should fix the immediate issue. I've also cherry-picked it into stable.

Context here is:

I think this is just junked up and I hadn't pushed this server when I claimed it works.

This is likely the next cause up the line:

I just saw this happen on this install (no metamta.differential.unified-comment-context) so my guess was probably incorrect.

Can you point out which parts of Contributing Bug Reports, User Guide: Prototype Applications and Support Resources are unclear to you with respect to this report so we can improve the documentation?

Yeah, consistency and like "attacker gets into your account and deletes all your stuff and it's gone forever and you are so very sad" and such.

We could probably just do unpublished for now and wait until we have a stronger use case for a real "archive".

Way better on my monitor now, thanks!

I am also fine with articulating meaningless corporate values.