See T13656 for followup.

Instances technically have a formal "Deleted" status -- but it isn't really used by anything, nothing ever puts them into that status, and there are no instances in that status. For consistency with existing CLI workflows, I'm going to rename this to "Destroyed".

A related issue is that I think nothing currently destroys S3 data. For most instances this isn't significant, but it isn't helping anything. This should likely be part of the database destruction step, although it can probably interact with the S3 bucket directly.

Since observed repositories version differently today, this strategy won't work -- but I can't come up with any valid reason to ever put a repository into a "write maintenance" mode anyway. I do imagine making observed repositories "replay" fetches into the push log (as though they were pushes) in the future, but that still won't make "write maintenance" on an observed repository meaningful, so it seems fine to just prevent putting non-hosted repositories into this mode.

A minor issue on the way to this is that calling synchronizeWorkingCopyBeforeWrite() with an omnipotent viewer will write to the WorkingCopyVersion table with a null userPHID, which shows as "Unknown Object" in the UI.

A useful maintenance operation for staging area repositories is to remove out-of-date staging refs: old diffs which have already landed. This is of some particular importance for large installs, since Git has a significant per-ref overhead for many operations until protocol v2: by the time a repository has ~50K refs, interacting with it in basically any way has become slow and cumbersome.

Sorry to hear that and hope everything is OK with you @epriestley.
I spent many hours learning from this high-quality code base.
Best of luck in whatever you do in the future.

D21668 should improve this behavior, although it's not an ideal or complete fix.

Was a pleasure, thank you for this project!

So long, and thanks for the fishes.

...this would need some kind of smarter scope guard...

I also can't get O_NONBLOCK to survive process exit on macOS. This is possibly because macOS is now zsh, and this RedHat bug suggests that zsh clears O_NONBLOCK:

arc may leave stdout/stderr nonblocking.

I'd be interested in collaborating with anyone who is interested in continuing community-supported maintenance of Phabricator.

secure002 and secure004 are likely easy to take out of service, since they're pure replicas.

See PHI2090 for another report of this. Chrome hasn't changed behavior since the last update, so I'm more inclined to look at workarounds.

A point against AllowEncodedSlashes Off which I hadn't connected the dots on is that "security researchers" from HackerOne will report URLs like this as "content injection vulnerabilities" for all time:

It may be doing it that way to avoid the possibility for missed timer overflows?

In T13652#255834, @epriestley wrote:

I'm starting with an absolute bottom-of-the-line 3018, I've "upgraded" it with a plotter collet I made out of a pool noodle and a piece of cable gland so I'm less likely to hurt myself for now:

So far, I've mostly been implementing controller software, following heavily in the footsteps of GRBL. I think I'm maybe ~25% of the way toward having a similar-ish capability set? But I don't really know what I'm doing, I am doing a few things a bit differently, and haven't written any meaningful amount of C in many years, and suspect I may run into a wall with the CPU.

One thing I've changed is that the computer tells the board what hardware it is connected to at startup, e.g. "Linear Stepper Axis 1 is enabled by pin 8, driven by pin 2, and direction is controlled by pin 5", since I'd like to be able to rewire the board without updating the software, and generally have more control over the hardware configuration, and have an arbitrarily large number of axes and actuators and blinking lights and whatnot. My motion commands then reference axis IDs ("2D linear motion on axis 0 and axis 1 to relative position 15, 35") instead of spatial axes like "X" and "Y" directly.

I'm starting with an absolute bottom-of-the-line 3018, I've "upgraded" it with a plotter collet I made out of a pool noodle and a piece of cable gland so I'm less likely to hurt myself for now:

Now that I realized this isn't an April fools joke (or if it is, it's kinda late...) anyway I have a whole lot of experience in this department, having built several cnc controllers. My latest one is using a beaglebone black but I also experimented quite a lot with an arduino running grbl and another one running on a $30 esp32 board. If you have any unanswered questions I'd be happy to comment. I should have slightly better than ignorant responses.

lol

The digestWithNamedKey() issue above generally impacts anything using immutable caches, so it can affect CSRF too.

• This is far afield from any application I have today, but it seems plausible to operate a small-scale DIY plastic foundry (Ref) that converts plastic waste into blanks for machining or injecting into machined molds.
  • The cost to just buy premade plastic blanks doesn't seem particularly high (roughly comparable to plywood?) although I know nothing about plastic qualities.
  • Unsurprisingly, it seems like the market for recycled plastic material doesn't have a lot of DIY buyers (unit sizes are often: 1,500 pounds; per metric ton; per 40,000 pound truckload; "*Only Quantities of 10k lbs Plus").
• There are a handful of people doing extremely high-precision DIY EDM machining (Ref).

Hmm okay that might only take effect at the time of making commits, though I've run into other issues where phabricator/arcanist fails to parse the contents of a commit message and forcing it to interpret as UTF-8 via --encoding utf-8 in the mercurial command has worked.

I don't think HGENCODING applies to the content of changesets, since that would invalidate the changeset hashes and the whole revision graph with it.

To clarify I think having the environment variable set as HGENCODING=utf-8 would be a possible solution/workaround.

I have not tried this out yet but mercurial claims to respect an HGENCODING environment variable (https://www.mercurial-scm.org/doc/hg.1.html#environment-variables). It's possible that setting this on the phabricator server might fix the issue by affecting any hg commands run by phabricator. Note that the environment variable would need to be set/exported for both the system user account which phabricator web server runs under (like httpd or nginx) and the system user account which the daemons run under, as they both run mercurial commands.

Is this workaround now the recommended way to deal with this issue / ever going to be merged into the code base?

This issue is still occurring.. the root cause is related to phabricator being set to allow-public. My fix still works and it would be nice if anyone here would support me bringing this upstream.