We could probably clean this up (it does look a lot like an error) but DarkConsole isn't exactly a shining example of perfect visual design anyway and I'll probably remember or catch this when it next gets a cleanup pass, some time in 3050.

Yeah it does, and I just didn't recall ever seeing this behavior and assumed "stack trace" meant "error".

It seems like that went through cleanly. I just did Stop + Start + bin/remote deploy on the affected hosts. I then launched a test instance with placement allocations on two of the affected services; it came up cleanly.

Beginning the stop/start stuff now.

I'm planning to stop/start these instances during the maintenance window today since getting the rebalance into production in the next five days seems wildly optimistic.

I made it as far as locala.phacility.com working right so maybe I got everything?

I think in D19196 the engine always generated uppercase text, but that got changed in D19200, perhaps?

how did this ever escape us

See email. An instance got an invite into an awkward state by cancelling the invite after the user had accepted it but before they registered an account.

The GRANT syntax also appears to have changed. We currently do this (in Phacility-specific code):

Also ignore the untamed-wilds branch, I'm just pulling it out of the wreckage of my explosion-prone laptop (see also T13168).

ignore me

(Yell if I'm assuming too much here.)

The fix I'd propose is:

This isn't meaningful, but we can raise a more specific error.

When you "Analyze", we include a stack trace of where the query was issued from so you can hunt it down if you aren't sure. Does that explain the behavior?

EC2 volume ddata005.phacility.net filled up, causing problems for instances hosted on db005, leading to PHI771. I'll dig back into the CloudWatch monitoring stuff I setup a few months ago and make the db hosts report storage metrics the same way the repo hosts already do.

Bumping this just to say that another team I work with wants to track WIP using count instead of points. In their case, they are a support team, so their board is populated by cross-tagging tasks that belong to other teams. When those cross-tag tasks have story points for the team that originated the task, the story points show on the support team, as well. This means that the support team can't default the story points to 1 just to get the count in WIP.

Oh also apparently query profiling doesn't always come up when you click on it, here is an example error

Via PHI773, filter_input_array(INPUT_ENV, FILTER_UNSAFE_RAW); does not appear to work if variables_order excludes E.

Plans, yes. Timing is trickier. Currently, we only have one outstanding request for this feature (PHI760, which mostly wants project.search). So it's in queue somewhere, but currently beyond the forecasting horizon.

@epriestley any timing/plans for expanding? Would love to replace our older user token flows with an OAuth flow. We'd need a few other methods though:

Conduit API methods define a getRequiredScope() method, which tells you the scope they require.

Are there any obvious ways to see scope requirements/availability today, even if it means spelunking into the source code?

• Install XCode. Find the secret "Install Command Line Tools" option inside the Hidden Chamber of XCode and click it.

xcode-select --install should be possible without a full XCode installation.

Build just the extension from source?

I'm going to look at improving the push logs a bit to show which rule blocked a push to address the actual use case in PHI765, which makes this more of a distance nice-to-have.

T1022 is possibly somewhat-vaguely-adjacent on symlink stuff.

@jcox do you know how to reproduce arc diff dying when you try to create certain types of diffs that move or remove symlinks? I think that's adjacent, if not identical to what's being talked about here.

I think the following change to src/applications/herald/controller/HeraldRuleController.php line 672 (as of 185c28f307e4) should provide an immediate improvement to at least indicate that they are different rules:

As a special case of this, if you commit an empty a.py file, then add content to it and also add a new empty b.py file in a commit on top of it, the new empty b.py will be detected as a copy of a.py based on the previous (empty) content of the file. I think Git is being pretty reasonable/consistent here, but this is potentially also expectation-defying:

Trying to reproduce this locally just hits the ft_doc.epochModified issue. I'm not immediately sure why the behavior differs between my local install and secure, but that issue probably needs to be fixed first.

Actually, I'm not entirely right in merging that task -- T13163 isn't quite the same as the other two issues here. I think they're similar, but the query text is relevant in the case of T13163. Notably:

ugh, zucchini