mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2025-12-11 01:10:09 +03:00
5 seconds delay for new/modify entry PUSH NOTIFICATION #648
Reference in New Issue
Block a user
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?
Originally created by @kamilos956 on GitHub.
Subject of the issue
Deployment environment
Your environment (Generated via diagnostics page)
Config (Generated via diagnostics page)
Show Running Config
Environment settings which are overridden:
Steps to reproduce
I used application 1-2 days, login first to MacBook and iPhone, then login to Brave. All is working fine, new / modify entry saving immediately. After 1 day of use, I have 5 seconds delay to edit / new entry saving. No matter is phone or browser. While delay saving icon freeze application and after that, works fine. What I found, I have this delay only while PUSH NOTIFICATION are enabled, when I disable all always is working fine. For this delay helps deauthorized all sessions from admin panel. After that is ok for another 1-2 days.
Expected behaviour
Always working with no delay.
Actual behaviour
5 seconds delay for new / modify entry. As you see below, ~4 seconds pause after created socket succesfully.
Troubleshooting data
[2023-11-18 08:49:43.387][request][INFO] DELETE /api/ciphers/07c621ce-d875-414a-8bdd-bf79f5c5b05b
[2023-11-18 08:49:43.436][reqwest::connect][DEBUG] starting new connection: https://identity.bitwarden.com/
[2023-11-18 08:49:43.436][trust_dns_proto::xfer::dns_handle][DEBUG] querying: identity.bitwarden.com A
[2023-11-18 08:49:43.436][trust_dns_resolver::name_server::name_server_pool][DEBUG] sending request: [Query { name: Name("identity.bitwarden.com"), query_type: A, query_class: IN }]
[2023-11-18 08:49:43.436][trust_dns_resolver::name_server::name_server][DEBUG] reconnecting: NameServerConfig { socket_addr: 127.0.0.11:53, protocol: Udp, tls_dns_name: None, trust_negative_responses: false, bind_addr: None }
[2023-11-18 08:49:43.436][trust_dns_proto::xfer][DEBUG] enqueueing message:QUERY:[Query { name: Name("identity.bitwarden.com"), query_type: A, query_class: IN }]
[2023-11-18 08:49:43.436][trust_dns_proto::udp::udp_client_stream][DEBUG] final message: ; header 2751:QUERY:RD:NoError:QUERY:0/0/0
; query
;; identity.bitwarden.com. IN A
[2023-11-18 08:49:43.436][trust_dns_proto::udp::udp_stream][DEBUG] created socket successfully
[2023-11-18 08:49:47.453][trust_dns_proto::udp::udp_client_stream][DEBUG] received message id: 2751
[2023-11-18 08:49:47.454][trust_dns_resolver::error][DEBUG] Response:; header 2751:RESPONSE:RD,RA:NoError:QUERY:2/0/0
; query
;; identity.bitwarden.com. IN A
; answers 2
@BlackDex commented on GitHub:
This could indeed be DNS related. I'm not really able to mimic the exact same though.
I'm going to move this too the Idea section. The only thing what might solve this specific item is that we somehow decouple the notifications code via a thread or something from the rest of the web-vault.
Since this is more of a performance/UX item and not a real bug ill remove it from issues.
@nomad2246 commented on GitHub:
Hi,
I had this same problem, or a very similar one.
I had the DNS of the container itself pointing to the server where it is hosted, the latter picked up the requests and sent them to cloudflared encrypted (DoH).
As soon as I point the DNS of the container directly to cloudflared (1.1.1.1.1/1.0.0.1) the delay when saving/modifying a vault element is over.