Conflicts:
- `README.md`:
Discarded upstream changes: we have our own README
- `app/controllers/follower_accounts_controller.rb`:
Port upstream's minor refactoring
Conflicts:
- `README.md`:
Discarded upstream changes: we have our own README
- `app/controllers/follower_accounts_controller.rb`:
Port upstream's minor refactoring
There is an idempotency key generated by clients when authoring a post,
and stored in Redis, to ensure that if a user or client retries posting
the same status, we don't get a duplicate.
Hachyderm.io has been experiencing some filesystem and database
performance issues, causing database writes to be slow. This can mean
that there are successful posts, but the reverse proxy returns 504
Gateway Timeout before the idempotency status has been updated; users or
clients who retry (such as Tusky which retries automatically, see
tuskyapp/Tusky#2951) can re-try the same post with the same idempotency
key before it has actually been recorded in Redis, leading to duplicate
posts.
To address this issue, move all of the database updates after the
initial transaction that creates the status into the
`postprocess_status!` method, so we can insert the idempotency key
immediately after the status has been created, significantly reducing
the window in which the status could be created but the idempotency key
not yet stored.
Note: this has not yet been tested; I'm submitting this PR for
discussion and to offer to the Hachyderm.io admins to try out to fix the
multiple posting problem.
Co-authored-by: Brian Campbell <brcampbell@beta.team>
There is an idempotency key generated by clients when authoring a post,
and stored in Redis, to ensure that if a user or client retries posting
the same status, we don't get a duplicate.
Hachyderm.io has been experiencing some filesystem and database
performance issues, causing database writes to be slow. This can mean
that there are successful posts, but the reverse proxy returns 504
Gateway Timeout before the idempotency status has been updated; users or
clients who retry (such as Tusky which retries automatically, see
tuskyapp/Tusky#2951) can re-try the same post with the same idempotency
key before it has actually been recorded in Redis, leading to duplicate
posts.
To address this issue, move all of the database updates after the
initial transaction that creates the status into the
`postprocess_status!` method, so we can insert the idempotency key
immediately after the status has been created, significantly reducing
the window in which the status could be created but the idempotency key
not yet stored.
Note: this has not yet been tested; I'm submitting this PR for
discussion and to offer to the Hachyderm.io admins to try out to fix the
multiple posting problem.
Co-authored-by: Brian Campbell <brcampbell@beta.team>
* Update nvmrc to Node.js 16
* Update package.json minimum Node engine to 16
* Update README requirements to Node.js 16
* Update devcontainer Node.js version to 16
* Update devcontainer Dockerfile Node.js choices to LTS versions that are still in support/maintenance
* Pin CircleCI Node image to 16
* Fix YAML type issue
* Update CircleCI Node.js to 16.18 to match #22019
* Update nvmrc to Node.js 16
* Update package.json minimum Node engine to 16
* Update README requirements to Node.js 16
* Update devcontainer Node.js version to 16
* Update devcontainer Dockerfile Node.js choices to LTS versions that are still in support/maintenance
* Pin CircleCI Node image to 16
* Fix YAML type issue
* Update CircleCI Node.js to 16.18 to match #22019
* Improve devcontainer for running tests
- Pull devcontainer post-create out into its own script
- Add asset precompilation
- Add test-mode asset precompilation (needed to run tests without error)
* Document Gemfile.lock re-checkout in devcontainer
* Improve devcontainer for running tests
- Pull devcontainer post-create out into its own script
- Add asset precompilation
- Add test-mode asset precompilation (needed to run tests without error)
* Document Gemfile.lock re-checkout in devcontainer
When opening a page such as /web/timelines/home in a desktop browser, the
cursor was automatically placed in the textarea of the compose form.
When using the keyboard for navigation (using a browser plugin like vimium or
vim vixen, or just to hit 'space' to scroll down a page), you have remember to
leave the field before using that.
Since you only visit the page to write a new post some of the time, this PR
attempts to have nothing focused initially (and require the user to click or
e.g. use 'tab' to focus the textarea).
Tested:
* /web/timeslines/home no longer autofocuses the compose box
* pressing the 'n' hotkey still focuses the compose box
* clicking 'reply' for a post still focuses the compose box
* replying to a CW'ed post still focuses the compose box
* introducing the CW field still focuses the CW field
* introducing the CW field for a reply still focuses the CW field
* removing the CW field still focuses the compose box
* /web/statuses/new still autofocuses the compose box
fixes#15862
When opening a page such as /web/timelines/home in a desktop browser, the
cursor was automatically placed in the textarea of the compose form.
When using the keyboard for navigation (using a browser plugin like vimium or
vim vixen, or just to hit 'space' to scroll down a page), you have remember to
leave the field before using that.
Since you only visit the page to write a new post some of the time, this PR
attempts to have nothing focused initially (and require the user to click or
e.g. use 'tab' to focus the textarea).
Tested:
* /web/timeslines/home no longer autofocuses the compose box
* pressing the 'n' hotkey still focuses the compose box
* clicking 'reply' for a post still focuses the compose box
* replying to a CW'ed post still focuses the compose box
* introducing the CW field still focuses the CW field
* introducing the CW field for a reply still focuses the CW field
* removing the CW field still focuses the compose box
* /web/statuses/new still autofocuses the compose box
fixes#15862
