I think pictures are part of a "story"? We can have users upload pictures and take pictures with phones. There doesn't seem to be a native CLI way to get Macbooks to take photos but we can make users brew install imagesnap, it seems, and then arc could update stories.

Thanks for the extremely thorough bug report. This should be fixed in HEAD of master, and promote to stable within about 72 hours.

I'd guess there is a ...->setContinueOnMissingFields(true)->... missing on an Editor somewhere.

Actually, that fix is completely bogus and there's no inverse edge type so this is perhaps somewhat more involved.

This is probably a one-line fix, but let me repro + get test coverage on it.

This is expected:

I can't reproduce this. Phriction is successfully public on this install:

It's a lot easier to merge stuff than split it, so don't worry about filing new stuff if there's any ambiguity. We can merge them with a couple clicks, but if you've really described a different issue then splitting them is much more of a pain.

(And it's easier to build query panels.)

I'm fine with getting rid of the template, I think it's much less relevant now that home is no longer a single dashboard.

I think we could even default it to "fancy mode" without a setting, at least to start with. I'm not sure anyone will want to access the plain text mode with enough frequency that we need it to be sticky.

While the git ls-remote change isn't really motivated as a performance improvement, it does seem to have reduced CPU usage a measurable amount (deployed on the morning of 3/18), maybe 15%:

The cause of this was mundane: the daemon queue has a large repository import in it, so the repository search update got stuck behind the import tasks. Manually forcing an index update with bin/search index Rx fixed the index.

I don't really consider this behavior a bug, because this (users registering into zero spaces) isn't really a supported workflow. The menu rendering is less ambiguously a bug, but I'd likely fix it by just hiding the menu in this state, and that won't address your issue. And it doesn't cause any problems unless you get into this questionable state in the first place, so cleaning it up is difficult to prioritize.

"Can Create (Non-Bot) Users" is a fake permission for Phacility SAAS disguised as a real permission. You must always have that permission and be an administrator to create users: that is, it can only be used to reduce the set of administrators who have permission to create users. In the Phacility SAAS cluster, we set this permission to "No One".

In the short term, if you want to email me at support@ with the details, I'll fix these manually. We've rarely seen this request and the cost to build this self-serve, even if it didn't have product issues, is greater than the cost to manually fix all known cases for now. I'll build some kind of self-serve solution at the point when I get tired of doing them manually.

We could conceivably do something like "edit this query" link from the panel, and have that take you to /application/query/wzyx/?panelPHID=asdf, and that generates a "save this query back to panel X" option in the UI.

Mine's fine here, too:

(Commit-date ordering would also mean that forward-dated commits would be stuck to the top forever.)

That is, we order things by discovery date (when we learned about the existence of the commit), which is tamper-proof, rather than author date or committer date, which are freely mutable by the client.

If you just updated after more than a year, you are probably seeing imports from the change in T6878. Once those finish, things will settle down and "commits" will begin reflecting what you expect.

Downgrading accepts and rejects (changing "Accepted" into "Accepted Older") uses raw edge transactions.

The Herald case and the next case (newAutoReviewTransaction()) both have some code duplication around prefiltering reviewers before building transactions for them.

Instead of using open registration, can you invite users instead and immediately add them to spaces so this doesn't happen? Why are you allowing open registration if all registration must be coordinated with an administrator anyway?

This is vaguely involved.

It sounds like this is resolved.

We don't plan to take any other upstream actions here, but let us know if anyone has further questions.

No, it would not.

This should now be fixed in HEAD of master. I've also cherry-picked it to stable. Thanks for the report!

I think this commit in the Git upstream is probably the culprit (January 2016):

Does it work without the --?

I can't immediately reproduce this, although the systems I have immediate access to are all running Git 2.11.0.

The setsid() appears to have resolved the issue, in the sense that daemons are now starting cleanly every time without receiving any inexplicable signals.

The MySQL stuff seems to be in the old daemons (them trying to do logging while MySQL restarts), not the new daemons, and not the cause of the issue.

We have no plans to move this forward or enable it in the Phacility cluster in the near future.

We can also do other stuff like "never archive an instance with 2+ users", "after an instance emails us to unsuspend, have a flag to mark it as exempt from cleanup in the future", "don't destroy data for 365 days, instead of 90, if an instance had hosted repositories", or other sorts of things like that, but I suspect measures like that will be largely unnecessary for years to come and that "no one loaded a page for 45 days" is already a nearly perfect signal for "no one cares about this instance".

Continuing from above, I queried a subset of instances for session counts to help us understand usage patterns for free instances (see T12217):

Picking a random shard, 80% of the active instances have zero sessions in the last 30 days -- so no user has loaded a single page in at least a month. Most (maybe all?) of these have only one account. These include (anonymized) free instances like "alsdknfasf", "test2", "test2017", "testinstance9", "testforme", "mytest", "myinstance", "bbbbbbb", "ddeemmoo". Of the 20% of active instances which do have activity in the last 30 days, many are recently-launched free instances with only one user session, and I'd guess many of those users are never coming back and these instances will join the boneyard shortly.

My thinking is that v1 would work like this:

I'm going to put D17497 + D17498 into this release even though they don't directly tackle the issue here and I think they're slightly risky changes (mostly because git ls-remote may have odd behaviors in some cases, and we don't currently use it in other workflows). But they may help with T12296 and general cluster load issues, and the followup changes will generally be more complicated to reason about (more locking/concurrency stuff), so I think getting these in earlier spreads risk out somewhat even though they're something to watch out for in this release.

Yep, that's what I'm thinking too.

Yeah, and the sane version (add to dashboard, not to tab panel) is probably not too awful and won't really make fixing T8033 any harder.

Getting rid of all "Select Existing Panel" flows also makes simplifying the "Run a query -> turn it into a panel -> put it on a dashboard" workflow a bit more of a mess, especially if we want to try to do "run a query -> turn it into a panel -> add it to a tab panel". But I think in the long term making the T8033 problem impossible and then trying to do our best with the "query -> panel -> dashboard" flow is the best bet.

As long as you're selecting existing panels in any interface, we're stuck with the problem in T8033. I think we can only fix that elegantly by removing all interfaces where you select panels, and replacing them with interfaces where you create panels.

The change I imagined there was: