- This feature was originally added in D1378.
- This feature was accidentally broken by D11169.
- In D19661, I removed the nonfunctional remnants of D1378.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Sep 11 2018
I wrote a patch for this, for both new log prototype and old log viewer here some screenshots for the view. If it is look OK, I will submit it.
This is now live.
Deploying the changes to web now.
Sep 10 2018
I've issued all instances a 24-hour service credit for the disruption. This should be reflected on your next invoice.
Here's the request rate leading up to the rate limiting:
D19653 (above) changes the per-"Host" rate limit to require "X-Forwarded-For" be present in the request. This should exempt ELB requests from these limits.
... [Mon Sep 10 20:48:43.928021 2018] [:error] [pid 21570] [client 172.30.0.171:16516] Array\n(\n [f] => \n [h] => 172.30.0.60\n)\n ...
... in production today as a next step.
This should have the pleasant side effect of letting us drop the goofy hard-coded internal rate limiting IP list.
There are four rate limits, and I don't currently have enough information to figure out which one triggered. The rate limits are:
The remaining work on the audit constants is:
See also PHI862 for a request for arc amend --force.
Sep 8 2018
Sep 7 2018
Sep 6 2018
See PHI860 and T13111. In the future, repository nodes may automatically gc/prune/repack. If they do, it may make sense to sort them to the bottom of the list so traffic is sent to them only if no other nodes are available, in order to minimize the impact that gc/prune/repack have on other activity.
PHI860 is a close variant of this and discusses periodically running git repack. Most concerns around git repack are likely similar to concerns around gc and prune.
D19637 doesn't actually improve this, but it brings us a step closer (since the logic is now in PHP and can be modified more easily to label symbols and add context).
Sep 5 2018
Yes. The diff is a relatively small amount of the work I must do to respond to this issue: install ElasticSearch, configure it in the way you describe, reproduce the issue, write or apply a change, verify it actually fixes the problem, go read through the documentation enough that I'm confident the fix is the best available fix and that we've understood the issue reasonably well.
Even if I'd provide the diff?
(Just to set expectations, anything which isn't coming in through Support Pacts may take a very long time for us to get to.)