User Deletion failed, and ended up being blocked
Summary
A free user contacted the Support team in this ticket, that their account was not deleted even though they tried to delete the account from Profile
> Account
-> Delete Account
.
Upon investigating, we found that the account was not deleted, but it was in the 'Blocked' state.
What is the current bug behavior?
Account is not deleted, but is blocked instead.
What is the expected correct behavior?
Account is deleted.
Relevant logs and/or screenshots
Links to logs are for internal use only.
- User tried to delete their account (Rails log): https://log.gprd.gitlab.net/goto/1243c3c0-ba00-11ec-b73f-692cc1ae8214
- But the deletion errored out (Sidekiq log): https://log.gprd.gitlab.net/goto/1b292390-ba00-11ec-afaf-2bca15dfbf33
- Snippets of the error message from sidekiq logs:
json.error_backtrace
lib/gitlab/database/load_balancing/connection_proxy.rb:119:in `block in write_using_load_balancer', lib/gitlab/database/load_balancing/load_balancer.rb:112:in `block in read_write', lib/gitlab/database/load_balancing/load_balancer.rb:179:in `retry_with_backoff', lib/gitlab/database/load_balancing/load_balancer.rb:110:in `read_write', lib/gitlab/database/load_balancing/connection_proxy.rb:118:in `write_using_load_balancer', lib/gitlab/database/load_balancing/connection_proxy.rb:60:in `block (2 levels) in <class:ConnectionProxy>', lib/gitlab/database/load_balancing/connection_proxy.rb:119:in `block in write_using_load_balancer', lib/gitlab/database/load_balancing/load_balancer.rb:112:in `block in read_write', lib/gitlab/database/load_balancing/load_balancer.rb:179:in `retry_with_backoff', lib/gitlab/database/load_balancing/load_balancer.rb:110:in `read_write', lib/gitlab/database/load_balancing/connection_proxy.rb:118:in `write_using_load_balancer', lib/gitlab/database/load_balancing/connection_proxy.rb:70:in `transaction', app/services/users/destroy_service.rb:68:in `execute', ee/app/services/ee/users/destroy_service.rb:10:in `execute', app/workers/delete_user_worker.rb:17:in `perform', lib/gitlab/database/load_balancing/sidekiq_server_middleware.rb:26:in `call', lib/gitlab/sidekiq_middleware/duplicate_jobs/strategies/until_executing.rb:16:in `perform', lib/gitlab/sidekiq_middleware/duplicate_jobs/duplicate_job.rb:58:in `perform', lib/gitlab/sidekiq_middleware/duplicate_jobs/server.rb:8:in `call', lib/gitlab/sidekiq_middleware/worker_context.rb:9:in `wrap_in_optional_context', lib/gitlab/sidekiq_middleware/worker_context/server.rb:17:in `block in call', lib/gitlab/application_context.rb:93:in `block in use', lib/gitlab/application_context.rb:93:in `use', lib/gitlab/application_context.rb:44:in `with_context', lib/gitlab/sidekiq_middleware/worker_context/server.rb:15:in `call', lib/gitlab/sidekiq_status/server_middleware.rb:7:in `call', lib/gitlab/sidekiq_versioning/middleware.rb:9:in `call', lib/gitlab/sidekiq_middleware/query_analyzer.rb:7:in `block in call', lib/gitlab/database/query_analyzer.rb:46:in `within', lib/gitlab/sidekiq_middleware/query_analyzer.rb:7:in `call', lib/gitlab/sidekiq_middleware/admin_mode/server.rb:14:in `call', lib/gitlab/sidekiq_middleware/instrumentation_logger.rb:9:in `call', lib/gitlab/sidekiq_middleware/batch_loader.rb:7:in `call', lib/gitlab/sidekiq_middleware/extra_done_log_metadata.rb:7:in `call', lib/gitlab/sidekiq_middleware/request_store_middleware.rb:10:in `block in call', lib/gitlab/with_request_store.rb:17:in `enabling_request_store', lib/gitlab/with_request_store.rb:10:in `with_request_store', lib/gitlab/sidekiq_middleware/request_store_middleware.rb:9:in `call', lib/gitlab/sidekiq_middleware/server_metrics.rb:74:in `block in call', lib/gitlab/sidekiq_middleware/server_metrics.rb:97:in `block in instrument', lib/gitlab/metrics/background_transaction.rb:33:in `run', lib/gitlab/sidekiq_middleware/server_metrics.rb:97:in `instrument', lib/gitlab/sidekiq_middleware/server_metrics.rb:73:in `call', lib/gitlab/sidekiq_middleware/monitor.rb:10:in `block in call', lib/gitlab/sidekiq_daemon/monitor.rb:49:in `within_job', lib/gitlab/sidekiq_middleware/monitor.rb:9:in `call', lib/gitlab/sidekiq_middleware/size_limiter/server.rb:13:in `call', lib/gitlab/sidekiq_logging/structured_logger.rb:21:in `call'
json.error_message
PG::NotNullViolation: ERROR: null value in column "author_id" violates not-null constraint
DETAIL: Failing row contains (9058716, null, null, 23849731, null, null, null, null, null, null, 2021-05-15 00:01:25.72869+00, 2022-03-04 16:48:31.374758+00, null, null, 3, 5, 2, f, f, Improper Control of Generation of Code ('Code Injection'), Improper Control of Generation of Code ('Code Injection'), null, , 0, 1900549, 3295218, 2022-03-04 16:48:31.133621+00, null, null, null, null, t, t, null).
CONTEXT: SQL statement "UPDATE ONLY "public"."vulnerabilities" SET "author_id" = NULL WHERE $1 OPERATOR(pg_catalog.=) "author_id""
- Did not find anything in Sentry.
Output of checks
This bug happens on GitLab.com: GitLab Enterprise Edition 14.10.0-pre dadfa240