When accessing a user of an instance whose original server failed, the first attempt fixed failure. #174
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What type of issue is this?
What happened?
When accessing a user of an instance whose original server failed, the first attempt fixed failure.
What did you expect to happen?
Firefish should not show an error message, but display the local content directly.
Steps to reproduce the issue
Reproduces how often
Once per account per instance per day.
What did you try to solve the issue / Do you have any insights
I suspect that the picture frame code is not fault-tolerant, but further verification is needed.
Version
v20240725
Instance
dvd.chat
What browser are you using? (client-side issues only)
What operating system are you using? (client-side issues only)
How do you deploy Firefish on your server? (server-side issues only)
What operating system are you using? (Server-side issues only)
Relevant log output
Contribution Guidelines
By submitting this issue, you agree to follow our Contribution Guidelines
Are you willing to fix this bug? (optional)
Author: laozhoubuluo
lastFetchedAtis a user attribute that needs to be modified in Postgres. I'm too lazy to change database in Postgres.Author: naskya
You can manually clear caches by deleting Redis keys
if you’re using the “db-container” setup, you can
$ make redis-clito enter the Redis CLI.Personally, I don’t think this is good, but the backend behavior changes depending on
NODE_ENV, so it may be related. Slow responses should be timed out as they can cause a DoS attack.Author: laozhoubuluo
The simulation of the server disconnection problem needs to wait for the cache to time out, and the test results need to be synchronized later.
But by the way, api/users/show calls resolveUser without a timeout mechanism. In the local test environment with slow network (network through proxy), we can see the problem that the backend has not completed the request but Nginx has timed out.
In this example, the frontend gave up after 1.5 minutes, and the backend completed the interface request after 6.5 minutes. I feel that there should be no problem in the production environment. I wonder if anyone have encountered this.
Author: laozhoubuluo
Author: laozhoubuluo
I reproduced the problem in the local test environment and found that the error message was still
Failed to WebFinger for wordlessecho@lolic.at: The operation was aborted.. After carefully checking the screenshots and code, I found that my local Git was not updated to 20240725. After the update, I found that resolveUserWebFinger could also throw this error.But I still have to try to know whether adding a catch here can fix the problem.
Author: naskya
Actually, we don’t need to use the
resolveSelffunction.packages/backend/src/remote/resolve-user.tshas been updated by the huge commit f282549900780a3413373dab444968d19db38102, and the Iceshrimp’s code should handle it better (but we may be using it wrong).Author: naskya
Thanks for your insights! If you can fix the problem, please feel free to open a merge request.
side note:
I believe the function name
resolveSelfis taken from the WebFinger spec (see https://info.firefish.dev/.well-known/webfinger?resource=acct:firefish@info.firefish.dev for example).I personally don’t think we need to stick to the word
self. Perhapsconst webfingerLink = ...is a better variable name?Author: laozhoubuluo
changed the description