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