[GH-ISSUE #2925] Emergency access fails if grantor doesnt log in during waiting time

kerem commented

2026-03-03 02:08:58 +03:00

Owner

Originally created by @SoleroTG on GitHub (Nov 18, 2022).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/2925

Originally assigned to: @BlackDex on GitHub.

Subject of the issue

When the grantee requests access to the grantor's vault, access isn't possible after the wait time if the grantor hasn't logged in during that time. Although the grantee received the Emergency access request for John Doe approved email, the Emergency Access tab of the grantee's account just lists the tags Emergency Access Initiated and View for the grantor user.

Deployment environment

Your environment (Generated via diagnostics page)

Vaultwarden version: v1.26.0
Web-vault version: v2022.10.0
Running within Docker: true (Base: Debian)
Environment settings overridden: true
Uses a reverse proxy: true
IP Header check: true (X-Real-IP)
Internet access: true
Internet access via a proxy: false
DNS Check: true
Time Check: true
Domain Configuration Check: true
HTTPS Check: true
Database type: SQLite
Database version: 3.35.4
Clients used:
Reverse proxy and version:
Other relevant information:

Config (Generated via diagnostics page)

Show Running Config

Environment settings which are overridden: DOMAIN, ADMIN_TOKEN, ALLOWED_IFRAME_ANCESTORS, SMTP_HOST, SMTP_SECURITY, SMTP_PORT, SMTP_FROM, SMTP_FROM_NAME, SMTP_USERNAME, SMTP_PASSWORD, SMTP_AUTH_MECHANISM

{
  "_duo_akey": null,
  "_enable_duo": false,
  "_enable_email_2fa": true,
  "_enable_smtp": true,
  "_enable_yubico": true,
  "_icon_service_csp": "",
  "_icon_service_url": "",
  "_ip_header_enabled": true,
  "admin_ratelimit_max_burst": 3,
  "admin_ratelimit_seconds": 300,
  "admin_token": "***",
  "allowed_iframe_ancestors": "*****.******.**",
  "attachments_folder": "data/attachments",
  "authenticator_disable_time_drift": false,
  "data_folder": "data",
  "database_conn_init": "",
  "database_max_conns": 10,
  "database_timeout": 30,
  "database_url": "****/**.*******",
  "db_connection_retries": 15,
  "disable_2fa_remember": true,
  "disable_admin_token": false,
  "disable_icon_download": false,
  "domain": "*****://*****.******.**",
  "domain_origin": "*****://*****.******.**",
  "domain_path": "",
  "domain_set": true,
  "duo_host": null,
  "duo_ikey": null,
  "duo_skey": null,
  "email_attempts_limit": 3,
  "email_expiration_time": 600,
  "email_token_size": 6,
  "emergency_access_allowed": true,
  "emergency_notification_reminder_schedule": "0 5 * * * *",
  "emergency_request_timeout_schedule": "0 5 * * * *",
  "enable_db_wal": true,
  "extended_logging": true,
  "helo_name": null,
  "hibp_api_key": null,
  "icon_blacklist_non_global_ips": true,
  "icon_blacklist_regex": null,
  "icon_cache_folder": "data/icon_cache",
  "icon_cache_negttl": 259200,
  "icon_cache_ttl": 2592000,
  "icon_download_timeout": 10,
  "icon_redirect_code": 302,
  "icon_service": "internal",
  "incomplete_2fa_schedule": "30 * * * * *",
  "incomplete_2fa_time_limit": 3,
  "invitation_expiration_hours": 120,
  "invitation_org_name": "Bitwarden",
  "invitations_allowed": false,
  "ip_header": "X-Real-IP",
  "job_poll_interval_ms": 30000,
  "log_file": null,
  "log_level": "Info",
  "log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f",
  "login_ratelimit_max_burst": 10,
  "login_ratelimit_seconds": 60,
  "org_attachment_limit": null,
  "org_creation_users": "*****@******.**",
  "password_hints_allowed": false,
  "password_iterations": 100000,
  "reload_templates": false,
  "require_device_email": false,
  "rsa_key_filename": "data/rsa_key",
  "send_purge_schedule": "0 5 * * * *",
  "sends_allowed": true,
  "sends_folder": "data/sends",
  "show_password_hint": false,
  "signups_allowed": false,
  "signups_domains_whitelist": "******.**,*******.**",
  "signups_verify": true,
  "signups_verify_resend_limit": 6,
  "signups_verify_resend_time": 3600,
  "smtp_accept_invalid_certs": false,
  "smtp_accept_invalid_hostnames": false,
  "smtp_auth_mechanism": "\"Plain\"",
  "smtp_debug": false,
  "smtp_explicit_tls": null,
  "smtp_from": "*******@*****.******.**",
  "smtp_from_name": "Bitwarden",
  "smtp_host": "****.******.**",
  "smtp_password": "***",
  "smtp_port": 465,
  "smtp_security": "force_tls",
  "smtp_ssl": null,
  "smtp_timeout": 15,
  "smtp_username": "******************",
  "templates_folder": "data/templates",
  "tmp_folder": "data/tmp",
  "trash_auto_delete_days": null,
  "trash_purge_schedule": "0 5 0 * * *",
  "use_syslog": false,
  "user_attachment_limit": null,
  "web_vault_enabled": true,
  "web_vault_folder": "web-vault/",
  "websocket_address": "0.0.0.0",
  "websocket_enabled": true,
  "websocket_port": 3012,
  "yubico_client_id": null,
  "yubico_secret_key": null,
  "yubico_server": null
}

Steps to reproduce

Create two users grantor and grantee
grantor is allowed to create organisations, grantee is not
grantor is owner in one group and grantee is user the same group
grantor grants grantee View access after one day of waiting
grantor logs out of all of his clients
grantee request access from grantor
grantor does not log in during that waiting time
grantee logs in and navigates to Emergency Access after receiving the Emergency access request for grantor approved email
the only available option for grantee when clicking the kebab menu is Remove

Expected behaviour

Grantee is able to access grantors vault after the waiting time.

Actual behaviour

Grantee cannot access grantors vault after the waiting time.

Originally created by @SoleroTG on GitHub (Nov 18, 2022). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/2925 Originally assigned to: @BlackDex on GitHub.   ### Subject of the issue When the grantee requests access to the grantor's vault, access isn't possible after the wait time if the grantor hasn't logged in during that time. Although the grantee received the `Emergency access request for John Doe approved` email, the `Emergency Access` tab of the grantee's account just lists the tags `Emergency Access` Initiated and `View` for the grantor user. ### Deployment environment #### Your environment (Generated via diagnostics page) * Vaultwarden version: v1.26.0 * Web-vault version: v2022.10.0 * Running within Docker: true (Base: Debian) * Environment settings overridden: true * Uses a reverse proxy: true * IP Header check: true (X-Real-IP) * Internet access: true * Internet access via a proxy: false * DNS Check: true * Time Check: true * Domain Configuration Check: true * HTTPS Check: true * Database type: SQLite * Database version: 3.35.4 * Clients used: * Reverse proxy and version: * Other relevant information: ### Config (Generated via diagnostics page) <details><summary>Show Running Config</summary> **Environment settings which are overridden:** DOMAIN, ADMIN_TOKEN, ALLOWED_IFRAME_ANCESTORS, SMTP_HOST, SMTP_SECURITY, SMTP_PORT, SMTP_FROM, SMTP_FROM_NAME, SMTP_USERNAME, SMTP_PASSWORD, SMTP_AUTH_MECHANISM ```json { "_duo_akey": null, "_enable_duo": false, "_enable_email_2fa": true, "_enable_smtp": true, "_enable_yubico": true, "_icon_service_csp": "", "_icon_service_url": "", "_ip_header_enabled": true, "admin_ratelimit_max_burst": 3, "admin_ratelimit_seconds": 300, "admin_token": "***", "allowed_iframe_ancestors": "*****.******.**", "attachments_folder": "data/attachments", "authenticator_disable_time_drift": false, "data_folder": "data", "database_conn_init": "", "database_max_conns": 10, "database_timeout": 30, "database_url": "****/**.*******", "db_connection_retries": 15, "disable_2fa_remember": true, "disable_admin_token": false, "disable_icon_download": false, "domain": "*****://*****.******.**", "domain_origin": "*****://*****.******.**", "domain_path": "", "domain_set": true, "duo_host": null, "duo_ikey": null, "duo_skey": null, "email_attempts_limit": 3, "email_expiration_time": 600, "email_token_size": 6, "emergency_access_allowed": true, "emergency_notification_reminder_schedule": "0 5 * * * *", "emergency_request_timeout_schedule": "0 5 * * * *", "enable_db_wal": true, "extended_logging": true, "helo_name": null, "hibp_api_key": null, "icon_blacklist_non_global_ips": true, "icon_blacklist_regex": null, "icon_cache_folder": "data/icon_cache", "icon_cache_negttl": 259200, "icon_cache_ttl": 2592000, "icon_download_timeout": 10, "icon_redirect_code": 302, "icon_service": "internal", "incomplete_2fa_schedule": "30 * * * * *", "incomplete_2fa_time_limit": 3, "invitation_expiration_hours": 120, "invitation_org_name": "Bitwarden", "invitations_allowed": false, "ip_header": "X-Real-IP", "job_poll_interval_ms": 30000, "log_file": null, "log_level": "Info", "log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f", "login_ratelimit_max_burst": 10, "login_ratelimit_seconds": 60, "org_attachment_limit": null, "org_creation_users": "*****@******.**", "password_hints_allowed": false, "password_iterations": 100000, "reload_templates": false, "require_device_email": false, "rsa_key_filename": "data/rsa_key", "send_purge_schedule": "0 5 * * * *", "sends_allowed": true, "sends_folder": "data/sends", "show_password_hint": false, "signups_allowed": false, "signups_domains_whitelist": "******.**,*******.**", "signups_verify": true, "signups_verify_resend_limit": 6, "signups_verify_resend_time": 3600, "smtp_accept_invalid_certs": false, "smtp_accept_invalid_hostnames": false, "smtp_auth_mechanism": "\"Plain\"", "smtp_debug": false, "smtp_explicit_tls": null, "smtp_from": "*******@*****.******.**", "smtp_from_name": "Bitwarden", "smtp_host": "****.******.**", "smtp_password": "***", "smtp_port": 465, "smtp_security": "force_tls", "smtp_ssl": null, "smtp_timeout": 15, "smtp_username": "******************", "templates_folder": "data/templates", "tmp_folder": "data/tmp", "trash_auto_delete_days": null, "trash_purge_schedule": "0 5 0 * * *", "use_syslog": false, "user_attachment_limit": null, "web_vault_enabled": true, "web_vault_folder": "web-vault/", "websocket_address": "0.0.0.0", "websocket_enabled": true, "websocket_port": 3012, "yubico_client_id": null, "yubico_secret_key": null, "yubico_server": null } ``` </details> ### Steps to reproduce 1. Create two users _grantor_ and _grantee_ 2. _grantor_ is allowed to create organisations, _grantee_ is not 3. _grantor_ is owner in one group and _grantee_ is user the same group 4. grantor grants grantee `View` access after one day of waiting 5. grantor logs out of all of his clients 6. grantee request access from grantor 7. grantor does not log in during that waiting time 8. grantee logs in and navigates to `Emergency Access` after receiving the `Emergency access request for grantor approved` email 9. the only available option for grantee when clicking the kebab menu is `Remove` ### Expected behaviour Grantee is able to access grantors vault after the waiting time. ### Actual behaviour Grantee cannot access grantors vault after the waiting time.

kerem

2026-03-03 02:08:58 +03:00

closed this issue
added the
enhancement

bug
labels

kerem commented

2026-03-03 02:08:59 +03:00

Author

Owner

@BlackDex commented on GitHub (Nov 18, 2022):

I have tested this just last week. And it all seems to work fine it looks like.

Are you sure the wait time is over?
What is the current status in the database? (emergency_access table).

If you are able to, please copy/paste/provide the following columns of the record you think is in error.

atype
status
wait_time_days
recovery_initiated_at
last_notification_at
updated_at
created_at

Also, please enable LOG_LEVEL=debug, that should provide some more info regarding the jobs running for the emergency access.

Also remember that the wait-time is checked during the scheduled job. That job is executed every hour at minute 5 of that hour.
So, 11:05, 12:05, 13:05 etc... If for example that requested timestamp is 13:06 the previous day, then you will have to wait for 14:05 for that request to be triggered.

Please provide the requested info so that we can try to help.

@BlackDex commented on GitHub (Nov 18, 2022): I have tested this just last week. And it all seems to work fine it looks like. 1. Are you sure the wait time is over? 2. What is the current status in the database? (`emergency_access` table). If you are able to, please copy/paste/provide the following columns of the record you think is in error. - `atype` - `status` - `wait_time_days` - `recovery_initiated_at` - `last_notification_at` - `updated_at` - `created_at` Also, please enable `LOG_LEVEL=debug`, that should provide some more info regarding the jobs running for the emergency access. Also remember that the `wait-time` is checked during the scheduled job. That job is executed every hour at minute 5 of that hour. So, `11:05`, `12:05`, `13:05` etc... If for example that requested timestamp is `13:06` the previous day, then you will have to wait for `14:05` for that request to be triggered. Please provide the requested info so that we can try to help.

kerem commented

2026-03-03 02:08:59 +03:00

Author

Owner

@SoleroTG commented on GitHub (Nov 18, 2022):

Thanks for the fast reply.
I tested it twice with a wait time of one hour. I tried to access the grantors vault after I received the email Emergency access request for grantor approved. I didn't wait much longer and reset both accounts afterwards. I run another try and post the results here, as requested.

@SoleroTG commented on GitHub (Nov 18, 2022): Thanks for the fast reply. I tested it twice with a wait time of one hour. I tried to access the grantors vault after I received the email `Emergency access request for grantor approved`. I didn't wait much longer and reset both accounts afterwards. I run another try and post the results here, as requested.

kerem commented

2026-03-03 02:08:59 +03:00

Author

Owner

@BlackDex commented on GitHub (Nov 18, 2022):

There is no wait time of an hour. There is a minimum of 1day.
So, if you expected it to be one hour, that is mistaken.

@BlackDex commented on GitHub (Nov 18, 2022): There is no wait time of an hour. There is a minimum of 1day. So, if you expected it to be one hour, that is mistaken.

kerem commented

2026-03-03 02:09:00 +03:00

Author

Owner

@SoleroTG commented on GitHub (Nov 18, 2022):

Thanks for the correction. I meant one day, of course.

@SoleroTG commented on GitHub (Nov 18, 2022): Thanks for the correction. I meant one day, of course.

kerem commented

2026-03-03 02:09:00 +03:00

Author

Owner

@SoleroTG commented on GitHub (Nov 19, 2022):

The already active run finished like the ones before.
I received the Emergency access request for grantor approved email at 17:05. Accessing the vault via grantee did not work.
After one and two hours later I still wasn't able to access the vault.

Now I set LOG_LEVEL=debug.

In the emergency_access table in db.sqlite3 I find
atype=0
status=3
wait_time_days=1
recovery_initiated_at=2022-11-18 15:39:15.342045184
last_notification_at=2022-11-18 15:39:15.342045184
updated_at=2022-11-19 18:05:16.410392218
created_at=2022-11-18 15:37:51.165740427

This confuses me as no emergency access is neither active nor pending.

I never messed with the database and just access the db via a offsite copy I took beforehand.

Should I still retry a new emergency access test? I think, that the entry in the emergency_access table situation should be solved before doing so.

@SoleroTG commented on GitHub (Nov 19, 2022): The already active run finished like the ones before. I received the `Emergency access request for grantor approved` email at 17:05. Accessing the vault via _grantee_ did not work. After one and two hours later I still wasn't able to access the vault. Now I set `LOG_LEVEL=debug`. In the `emergency_access` table in db.sqlite3 I find `atype=0` `status=3` `wait_time_days=1` `recovery_initiated_at=2022-11-18 15:39:15.342045184` `last_notification_at=2022-11-18 15:39:15.342045184` `updated_at=2022-11-19 18:05:16.410392218` `created_at=2022-11-18 15:37:51.165740427` This confuses me as no emergency access is neither active nor pending. I never messed with the database and just access the db via a offsite copy I took beforehand. Should I still retry a new emergency access test? I think, that the entry in the emergency_access table situation should be solved before doing so.

kerem commented

2026-03-03 02:09:00 +03:00

Author

Owner

@BlackDex commented on GitHub (Nov 19, 2022):

Strange, it does mention it was updated, but the status is still at 3, which i think from the top of my mind should be 4.

Please enable debug log level, and keep it running. It should keep trying the same, since the status is not correct yet.

@BlackDex commented on GitHub (Nov 19, 2022): Strange, it does mention it was updated, but the status is still at 3, which i think from the top of my mind should be 4. Please enable debug log level, and keep it running. It should keep trying the same, since the status is not correct yet.

kerem commented

2026-03-03 02:09:00 +03:00

Author

Owner

@SoleroTG commented on GitHub (Nov 20, 2022):

Just a small update:
The emergency_access table still shows the same content, although no emergency job being neither active no pending. Should I expect a cronjob fixing the entry?

The only log entries related to this are:

[2022-11-20 01:05:06.664][vaultwarden::api::core::emergency_access][DEBUG] Start emergency_notification_reminder_job
[2022-11-20 01:05:06.664][vaultwarden::api::core::emergency_access][DEBUG] Start emergency_request_timeout_job
[2022-11-20 01:05:06.665][vaultwarden::api::core::emergency_access][DEBUG] No emergency request timeout to approve
[2022-11-20 01:05:06.665][vaultwarden::api::core::emergency_access][DEBUG] No emergency request reminder notification to send

I'm grateful for any advice about what I can or should try next?

@SoleroTG commented on GitHub (Nov 20, 2022): Just a small update: The `emergency_access` table still shows the same content, although no emergency job being neither active no pending. Should I expect a cronjob fixing the entry? The only log entries related to this are: ``` [2022-11-20 01:05:06.664][vaultwarden::api::core::emergency_access][DEBUG] Start emergency_notification_reminder_job [2022-11-20 01:05:06.664][vaultwarden::api::core::emergency_access][DEBUG] Start emergency_request_timeout_job [2022-11-20 01:05:06.665][vaultwarden::api::core::emergency_access][DEBUG] No emergency request timeout to approve [2022-11-20 01:05:06.665][vaultwarden::api::core::emergency_access][DEBUG] No emergency request reminder notification to send ``` I'm grateful for any advice about what I can or should try next?

kerem commented

2026-03-03 02:09:00 +03:00

Author

Owner

@SoleroTG commented on GitHub (Nov 21, 2022):

Regarding the emergency access I am just getting the above posted entries about no emergency request being active (which is true atm).
The entry in the emergency_access table still exists.

Can I manually delete this entry?

@SoleroTG commented on GitHub (Nov 21, 2022): Regarding the emergency access I am just getting the above posted entries about no emergency request being active (which is true atm). The entry in the `emergency_access` table still exists. Can I manually delete this entry?

kerem commented

2026-03-03 02:09:00 +03:00

Author

Owner

@stefan0xC commented on GitHub (Nov 21, 2022):

Can I manually delete this entry?

If you remove the grantee as grantor (or yourself as grantee) the entry should be deleted as well.

I'm grateful for any advice about what I can or should try next?

You could try a PRAGMA integrity_check on the sqlite database.

@stefan0xC commented on GitHub (Nov 21, 2022): > Can I manually delete this entry? If you remove the grantee as grantor (or yourself as grantee) the entry should be deleted as well. > I'm grateful for any advice about what I can or should try next? You could try a `PRAGMA integrity_check` on the sqlite database.

kerem commented

2026-03-03 02:09:00 +03:00

Author

Owner

@BlackDex commented on GitHub (Nov 21, 2022):

If you want to grant your self access by an already approved access, which means ot shared the keys. The you can change the status your self too 4. Else you should also be able to remove the access on either side via the web-vault.

@BlackDex commented on GitHub (Nov 21, 2022): If you want to grant your self access by an already approved access, which means ot shared the keys. The you can change the status your self too 4. Else you should also be able to remove the access on either side via the web-vault.

kerem commented

2026-03-03 02:09:00 +03:00

Author

Owner

@SoleroTG commented on GitHub (Nov 21, 2022):

If you remove the grantee as grantor (or yourself as grantee) the entry should be deleted as well.

Right now, no user is shown neither as grantor nor grantee in the ui. This is consistent with my actions in the ui.

You could try a PRAGMA integrity_check on the sqlite database.

I ran the command and received integrity_check OK
The line in the emergency_access table, however, is still there.

The you can change the status your self too 4. Else you should also be able to remove the access on either side via the web-vault.

I changed the status in the emergency_access table from 3 to 4. This made the entry disappear in the db. Looks good so far.

Now I try again to give grantee emergency access and will post the result here.

Thanks for the help. I keep you updated.

@SoleroTG commented on GitHub (Nov 21, 2022): > If you remove the grantee as grantor (or yourself as grantee) the entry should be deleted as well. Right now, no user is shown neither as grantor nor grantee in the ui. This is consistent with my actions in the ui. > You could try a PRAGMA integrity_check on the sqlite database. I ran the command and received `integrity_check OK` The line in the `emergency_access` table, however, is still there. > The you can change the status your self too 4. Else you should also be able to remove the access on either side via the web-vault. I changed the `status` in the `emergency_access` table from 3 to 4. This made the entry disappear in the db. Looks good so far. Now I try again to give grantee emergency access and will post the result here. Thanks for the help. I keep you updated.

kerem commented

2026-03-03 02:09:00 +03:00

Author

Owner

@SoleroTG commented on GitHub (Nov 22, 2022):

It worked.
After I manipulated the db directly and set the status in the emergency_access table from 3 to 4 it worked like a charm.
Although, I have no idea how this corrupt entry appeared in the first place, I am happy that it is working now.

Thanks a lot for the support.

@SoleroTG commented on GitHub (Nov 22, 2022): It worked. After I manipulated the db directly and set the status in the `emergency_access` table from `3` to `4` it worked like a charm. Although, I have no idea how this corrupt entry appeared in the first place, I am happy that it is working now. Thanks a lot for the support.

kerem commented

2026-03-03 02:09:00 +03:00

Author

Owner

@BlackDex commented on GitHub (Nov 23, 2022):

Was it corrupted in which sense? Only the state was wrong? Or the database had issues?

As a side note. While i was checking the code, i saw some small enhancements for the code handeling this. I'll see if i can optimize the code a bit and maybe i will encounter something strange that could explain this behaviour.

@BlackDex commented on GitHub (Nov 23, 2022): Was it corrupted in which sense? Only the state was wrong? Or the database had issues? As a side note. While i was checking the code, i saw some small enhancements for the code handeling this. I'll see if i can optimize the code a bit and maybe i will encounter something strange that could explain this behaviour.

kerem commented

2026-03-03 02:09:00 +03:00

Author

Owner

@BlackDex commented on GitHub (Nov 23, 2022):

I might have found something which could cause this specific issue.
There could be some race-conditions and that could cause strange behaviors.

@BlackDex commented on GitHub (Nov 23, 2022): I might have found something which could cause this specific issue. There could be some race-conditions and that could cause strange behaviors.

kerem commented

2026-03-03 02:09:00 +03:00

Author

Owner

@SoleroTG commented on GitHub (Nov 23, 2022):

Was it corrupted in which sense? Only the state was wrong? Or the database had issues?

The database itself was consistent. With the term corrupted I mean that the database was in a state in which the application didn't function correctly and wasn't able to correct itself. If the term corrupted doesn't fit here I take it back and may as well call it in a funny state.

Anyhow, thanks again for the fast support.

@SoleroTG commented on GitHub (Nov 23, 2022): > Was it corrupted in which sense? Only the state was wrong? Or the database had issues? The database itself was consistent. With the term _corrupted_ I mean that the database was in a state in which the application didn't function correctly and wasn't able to correct itself. If the term _corrupted_ doesn't fit here I take it back and may as well call it _in a funny state_. Anyhow, thanks again for the fast support.

kerem commented

2026-03-03 02:09:01 +03:00

Author

Owner

@BlackDex commented on GitHub (Nov 23, 2022):

To make the terms a bit more clear. A corrupt database is a database which isn't functioning at all.
A record with an invalid state is what was causing the issue.

The reason it is important, a corrupt database could also cause some strange issue, including not being able to update a record.
But, if the database was valid, then there might be a coding issue.

As already mentioned, I think i have found what could cause this. One way of fixing this your self would be to change the schedules of the two emergency access jobs in such a way that they will never run at the same time.

I keep this issue open until i finished the changes to the emergency access code.

@BlackDex commented on GitHub (Nov 23, 2022): To make the terms a bit more clear. A corrupt database is a database which isn't functioning at all. A record with an invalid state is what was causing the issue. The reason it is important, a corrupt database could also cause some strange issue, including not being able to update a record. But, if the database was valid, then there might be a coding issue. As already mentioned, I think i have found what could cause this. One way of fixing this your self would be to change the schedules of the two emergency access jobs in such a way that they will never run at the same time. I keep this issue open until i finished the changes to the emergency access code.

kerem referenced this issue

2026-03-03 09:09:06 +03:00

[PR #1415] [CLOSED] Slim #2955

Rows
Columns

[GH-ISSUE #2925] Emergency access fails if grantor doesnt log in during waiting time #1415

Subject of the issue

Deployment environment

Your environment (Generated via diagnostics page)

Config (Generated via diagnostics page)

Steps to reproduce

Expected behaviour

Actual behaviour