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?
Some evidence it probably actually works:
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).
(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?
I think this is a good practical fix to PHI622, particularly considering that summary is already present.
Thu, Jul 19
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.
I suppose reversing phutil_utf8v_combined() is a reasonably good approximation of a UTF8 reverser. It's probably not perfect (e.g., RTL marks should be inverted, I guess?) but if we were to implement phutil_utf8_strrev(), reversing phutil_utf8v_combined() would probably be a reasonable v0.
(Practically, we don't have a "...xxx" truncator either, and we can't just strrev() the input and output because we don't have a UTF8-aware string reverser.)
I think structuring it as The public key ending in "...<xyz>". is at least a little weird, and potentially confusing even if it's technically better in most cases.
Isn't the end of the public key way more useful for human readability in general?
(C02TW3N0HTDD is the very useful totally human interpretable name of my laptop)
Isn't the end of the public key way more useful for human readability in general? Most of my keys generated via ssh-keygen (which I assume the practically universal method?) end in an identifier that I can plausibly use to identify the key, like this one:
Wed, Jul 18
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?