I can not reproduce this issue by following your reproduction steps. Here's what I see on this install:

I've marked D15705 as fixing this, since it makes our interpretation of the path unambiguous: we would no longer interpret /ws/ as a request for namespace "ws".

Sorry about breaking this -- there are a lot of large changes going in this week related to T10751, so master might be a little less stable than usual until the dust settles there.

This should now be fixed in HEAD.

This report does not include reproduction steps. See Providing Reproduction Steps for help.

Upgrade Phabricator. This is fixed in HEAD.

This should be fixed in HEAD of master. Thanks for the report, let us know if you run into anything else.

Not 100% sure that's a fix, but I was able to reproduce something that looked similar and that appeared to fix it locally.

You can put lines=30 or similar after the triple backticks in the header:

(You may need to censor Authorization header bodies.)

What does GIT_CURL_VERBOSE=1 GIT_TRACE=1 look like for GitHub in your environment?

We need a good "Ph" currency name before I can really get maximally excited about it.

Since Windows tends to languish near the bottom of the priority list and I'm fairly confident this patch is fine, I'll accept it upstream if you use it for a couple days and nothing explodes and want to submit it.

I suspect that fix is safe and correct. It would be nice to kick the tires a little more before applying it and maybe try to dream up some test coverage, but it shouldn't have broader implications within the arc ecosystem.

T5953 might have some kind of options for this eventually with a longer timeline between polling checks (e.g., once an hour) but that's probably some ways away and probably wouldn't be a primary focus.

See T5834 for previous discussion.

this guy is pretty cool I like him 🐗

Per T6915, I'm likely to split the Phabricator side config into a list of services. If you run multiple servers, you list all of them and Phabricator can survive the loss of some subset gracefully. This should be easier for everyone to configure, too.

I'm currently thinking about making this configuration push-based instead of pull-based: each server is told about other servers it should publish to when it starts up. When it receives a notification, it publishes to all those servers (with reasonable mechanisms in place to prevent cycles).

This report doesn't have reproduction instructions (see Providing Reproduction Steps) and is likely obsoleted by T10697.

• D15695 should fix logged-out users.
• D15696 + D15697 should smooth out security.require-https for intracluster requests.

There's an overview of a different third-generation endpoint, owners.search, here:

It's available on maniphest.search.

Given current progress and velocity, I'm aiming for a timeline roughly like this:

I've started moving these changes into production (T10784) so I can begin gathering confidence that they actually work. The repository stuff definitely still doesn't work since several core pieces are currently implemented as // TODO comments, but it has the synchronization bookkeeping in place for all the locking/versioning: if that's stable, it will give me confidence that we're on relatively firm ground and can move forward.

This should be resolved at HEAD of master; updating Phabricator should restore things to working order.

I happen to know this one offhand.

Quoting and signature stripping works properly in major clients -- you can find the implementation here:

This is the same as T4181, sort of, except that merged somewhere else and isn't the same as itself, if you will.

Maybe T8646 is a closer match? Dupe of one or the other in any case, I think.

Ah, yep, thanks.

This sort of works now. The 002 node is live, just not reachable yet. Some weird stuff I hit:

I'm probably going to break all repositories momentarily. If I do, I'll try to fix them.

Very minor technical note: we can't support this for all providers. The username + password, LDAP, and I think Persona (although see T10125) providers can't initiate a login flow with a redirect (since the user has to type stuff or do javascriptey things, not just navigate to a URI).

sure.

That feature exists, but it's currently only supported for the Phabricator provider. There's no technical reason we can't support it on other providers, it was just built very narrowly for a Phacility (SAAS) use case and it was simpler to keep it narrowly scoped:

Some additional cases with this:

and assigned to seems to be an essential information

This request does not describe a root problem; instead, it asks for a specific feature. See Describing Root Problems for help.

Progress so far:

Looks like D15680 worked.

Hrrm, that's buggy.