pitchfork is a unicorn fork with some things removed and some things added.
We don't need any of these things so it should be an easy replace.
There is no worker-killer for pitchfork, it is however trivial to implement ourselves.
unicorn is pretty much dead. The author implies as much in the various readme updates
he made. It also doesn't work with rack 3 and I doubt a new release will even be made.
If it will, it highly likely won't be on rubygems.
This was previously mistyped which made it fall back to the default of 60 seconds.
Apparently 5 is not enough since there are a few errors on prod for this
Since its introduction 3 years ago, it got used once I believe
I can't even say if this properly works anymore.
If something like that is actually desired in the future, it should just be a whitelist instead
It just works.
Requires a bit of a workaround for the .rubocop.yml env setup currently in use but thats alright.
The companion ruby-lsp-rails doesn't do much right now but I imagine that to become quite powerful in the future.
Removing the app root already happens by default, in a more correct manner.
Fixes the following type of backtraces:
app/decoratorslication_decorator.rb:1:in `<main>'
=>
app/decorators/application_decorator.rb:1:in `<main>'
Run the following commands to import data into OpenSearch:
Post.document_store.create_index!
PostVersion.document_store.create_index!
Post.document_store.import
PostVersion.document_store.import
* Add opensearch client
* Add url param to force use opensearch
* Switch import method over to opensearch
* Index to opensearch as well
* Add option to gradually roll out os
* Index os with separate queue
* Move os post creation to job as well
* Exclusively use the OpenSearch client
* Stop enqueuing OsIndexUpdateJob
* Remove remaining elasticsearch code
Bump faraday since v2 is no longer blocked
There is no counterpart for OpenSearch.
`elasticsearch-model` needs to go too but that is more involved than
just removing something that only facilitates logging in dev.
This was responsible for
* displaying the time elasticsearch queries took per request
* logging the search parameters being sent to elasticsearch per query
The implementation isn't that complex and I could roll something myself but
considering that I haven't sought that information out by now I'll just don't.
Logging queries is trivial since we craft these manually ourselves.
The constraint applies to all user routes, which includes `custom_style`.
Also fixes a constant redefinition warning in the console when doing `reload!`
There is no proper show action for api keys. Just do a redirect instead.
Remove a duplicate view action from the routes, be explicit that a show action exists
Most of that is not easily configurable and requires db fields, css classes etc.
Everything in TagCategory was also pretty much incomprehensible for me
thanks to the indirection, so I moved it all inline instead.
I'll clean that up in later commits.
