Approval rules API returning an error 500

Summary

One of our customers reported an error 500 when using the approval rules API.

Looking at the logs on our end is:

      "exception.class": "ArgumentError",
...
      "exception.backtrace": [
        "lib/gitlab/database/load_balancing/connection_proxy.rb:127:in `public_send'",
        "lib/gitlab/database/load_balancing/connection_proxy.rb:127:in `block in write_using_load_balancer'",
        "lib/gitlab/database/load_balancing/load_balancer.rb:141:in `block in read_write'",
        "lib/gitlab/database/load_balancing/load_balancer.rb:235:in `retry_with_backoff'",
        "lib/gitlab/database/load_balancing/load_balancer.rb:130:in `read_write'",
        "lib/gitlab/database/load_balancing/connection_proxy.rb:126:in `write_using_load_balancer'",
        "lib/gitlab/database/load_balancing/connection_proxy.rb:78:in `transaction'",
        "ee/app/services/concerns/approval_rules/updater.rb:101:in `block in update_rule'",
        "ee/lib/ee/gitlab/audit/auditor.rb:13:in `multiple_audit'",
        "lib/gitlab/audit/auditor.rb:56:in `audit'",
        "ee/app/services/concerns/approval_rules/updater.rb:101:in `update_rule'",
        "ee/app/services/concerns/approval_rules/updater.rb:39:in `action'",
        "ee/app/services/approval_rules/base_service.rb:8:in `execute'",
        "ee/app/services/concerns/approval_rules/updater.rb:15:in `execute'",
        "ee/lib/api/helpers/project_approval_rules_helpers.rb:80:in `create_project_approval_rule'",
        "ee/lib/api/project_approval_rules.rb:40:in `block (3 levels) in <class:ProjectApprovalRules>'",
        "ee/lib/gitlab/middleware/ip_restrictor.rb:14:in `block in call'",
        "ee/lib/gitlab/ip_address_state.rb:10:in `with'",
        "ee/lib/gitlab/middleware/ip_restrictor.rb:13:in `call'",
        "lib/api/api_guard.rb:219:in `call'",
        "ee/lib/omni_auth/strategies/group_saml.rb:41:in `other_phase'",
        "lib/gitlab/metrics/elasticsearch_rack_middleware.rb:16:in `call'",
        "lib/gitlab/middleware/memory_report.rb:13:in `call'",
        "lib/gitlab/middleware/speedscope.rb:13:in `call'",
        "lib/gitlab/database/load_balancing/rack_middleware.rb:23:in `call'",
        "lib/gitlab/middleware/rails_queue_duration.rb:33:in `call'",
        "lib/gitlab/etag_caching/middleware.rb:21:in `call'",
        "lib/gitlab/metrics/rack_middleware.rb:16:in `block in call'",
        "lib/gitlab/metrics/web_transaction.rb:46:in `run'",
        "lib/gitlab/metrics/rack_middleware.rb:16:in `call'",
        "lib/gitlab/middleware/go.rb:20:in `call'",
        "lib/gitlab/middleware/query_analyzer.rb:11:in `block in call'",
        "lib/gitlab/database/query_analyzer.rb:40:in `within'",
        "lib/gitlab/middleware/query_analyzer.rb:11:in `call'",
        "lib/gitlab/middleware/organizations/current.rb:20:in `call'",
        "lib/gitlab/middleware/multipart.rb:173:in `call'",
        "lib/gitlab/middleware/read_only/controller.rb:50:in `call'",
        "lib/gitlab/middleware/read_only.rb:18:in `call'",
        "lib/gitlab/middleware/unauthenticated_session_expiry.rb:18:in `call'",
        "lib/gitlab/middleware/same_site_cookies.rb:27:in `call'",
        "lib/gitlab/middleware/path_traversal_check.rb:35:in `call'",
        "lib/gitlab/middleware/handle_malformed_strings.rb:21:in `call'",
        "lib/gitlab/middleware/basic_health_check.rb:25:in `call'",
        "lib/gitlab/middleware/handle_ip_spoof_attack_error.rb:25:in `call'",
        "lib/gitlab/middleware/request_context.rb:15:in `call'",
        "lib/gitlab/middleware/webhook_recursion_detection.rb:15:in `call'",
        "config/initializers/fix_local_cache_middleware.rb:11:in `call'",
        "lib/gitlab/middleware/compressed_json.rb:44:in `call'",
        "lib/gitlab/middleware/rack_multipart_tempfile_factory.rb:19:in `call'",
        "lib/gitlab/middleware/sidekiq_web_static.rb:20:in `call'",
        "lib/gitlab/metrics/requests_rack_middleware.rb:79:in `call'",
        "lib/gitlab/middleware/release_env.rb:13:in `call'"
      ],

Looking at Sentry, it appears the main error is: 'Coverage-Check' is not a valid report_type

What is the current bug behavior?

API fails without any helpful information for the user.

What is the expected correct behavior?

Return a message to the user about invalid report_type instead of failing with an error 500.