Current plan here is:

@tycho.tatitscheff See T8656 or Planning.

Unfortunately, this bug is reproducible on my installation by simply visiting the Diffusion URL, there are no other steps.

See also:

This has been open for several months without forward progress.

It seems like this isn't reproducible in other environments. Feel free to file a new report if you are able to uncover more information in the future.

Note that those are the actual names of the tabs (not, say, some weird internal hash, as I thought at first glance), the list just isn't getting rendered properly:

This is real dumb, but I think it only creates a moderate inconvenience so I probably won't try to dig into it until we do the next iteration on dashboards.

That fix isn't retroactive, but should stop the problem in the future once it deploys. Thanks for the report!

Thanks, pretty sure that's the issue. Diff in a sec.

Did you select "Disable Mail" from the "Members" page after joining the project?

...except that I can't reproduce it locally. Hrrm..

This is probably the "implicit membership" edge leaking through. Should be an easy fix.

I'd like to wait for a better use case before trying to separate protocol filtering in link/redirection contexts. Linking to a wiki page or similar seems reasonable in footers, and there's diversity and some security complications in other affected contexts (today: object profile menus, footer links, core external redirects, "Link" custom fields, {nav} elements, OAuth callback URIs).

I don't anticipate ever building this. It would take months and only partially address a very narrow range of primarily operational use cases.

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

Pretty sure this is the same user as @9999999999, @Persona, @nagya and @nagym. They're just registering an account every day, being vaguely annoying, and then getting disabled. O.o

D15358 should fix this by declaring the property. Nice catch on finding this!

Specifically, the issue is that this class extends Phobject, which implements __set() and throws when an undeclared property is written to. The exception is swallowed elsewhere in the stack.

This is detailed in T10463, but the API changes seem to have deployed with only a few minor rough patches, so we're currently on track to deploy everything else next Saturday (March 5).

Test instance workflow looks good, and general monitoring also looks clean. I'll keep an eye on things but I think we're in the clear.

Also, the backup changes from last week (rCOREbf0c93a46f8b) seem to have worked correctly. The instances that were hitting problems and delays have written backups exactly on schedule every day since then.

Daemons look good -- we accumulated a bit of a queue of backup tasks while the tier was out of sync, but these have now almost completely flushed on their own.

I've deployed the remainder of the repo tier, and the auxiliary service tiers. I believe deployment is essentially complete.

repo001 seems to have gone smoothly and daemons/repositories are now restored, I'm deploying the remainder of the tier.

db tier is deployed, now deploying repo001.

I've upgraded db001 and sorted out host instances and service sync flows, which seem OK now. I'm going to upgrade the rest of the db tier.

web is sort of back up, but needs the new schema to actually make any progress, so this isn't conclusive. I'm deploying the db tier now to get the new schema.

• I stopped web.
• I deployed admin.
• I manually removed now-invalid configuration from instances and from Alamanac properties.
• I spot-checked instance/Almanac service relationships.
• I spot-checked Almanac service properties.
• I manually invoked almanac.service.search to look for issues, but everything looks good.

I've stopped the daemons. I'm going to stop the web tier, deploy admin, fix instance configuration, then deploy the web tier. I expect this to be the riskiest part of the upgrade.

I'm getting this underway now. I'm going to preemptively stop all daemons, which will pause repository imports, outgoing mail, etc. They'll be restarted at the end of the process.

Pretty sure I can scope this into the current iteration under T10457 and provide some corresponding purge tools, just in case any installs hypothetically insert gigabytes of data into build logs.

In any case, this is definitely some kind of problem in your local environment and not an issue with the upstream. We can't and won't be able to reproduce it and can't help you with installation and setup issues (see Support Resources).

Oh, wait, you're actually on stable and just haven't updated master.

This column and the property for it were both removed in 32225d1 (Feb 8). You are running b5518d4b (Feb 7), but have somehow upgraded your database using a newer version of Phabricator.

A workaround is to write a wiki page like "how to get help with stuff" and put the link there.

My broad philosophical stance here is that engineers should be disciplined and professional about not killing enemy builds, but I think the complexity cost to put some more guard rails on the thing isn't overbearing and these additional policies are generally pretty reasonable and make sense, and have some redeeming value in preventing mistakes with tools like "Restart All Builds".

Presuming resolved by D15350.

Maybe a more natural approach to this would be to add a "Notify" build step? We'd also need an "on failure" set of actions or something which implicitly accomplished the same goal, but that seems reasonable to me.