Error in IssuesController when using an invalid issue_type

Summary

When setting the issue[issue_type] in the new issue url, a 500 error occurs when an invalid issue type is provided.

This was noticed while reviewing !43310 (merged)

Steps to reproduce

Visit .../-/issues/new?issue[issue_type]=UNHANDLED

Any value other than incident and issue will cause the error.

Example Project

Visit the link below:

https://gitlab.com/gitlab-org/gitlab/-/issues/new?issue[issue_type]=UNHANDLED

What is the current bug behavior?

500 error

What is the expected correct behavior?

Invalid values should use the default Issue type from the issues model

Relevant logs and/or screenshots

From my local dev environment:

ArgumentError - 'UNHANDLED' is not a valid issue_type:
  app/services/issues/build_service.rb:9:in `execute'
  app/controllers/projects/issues_controller.rb:98:in `new'
  ee/lib/gitlab/ip_address_state.rb:10:in `with'
  ee/app/controllers/ee/application_controller.rb:44:in `set_current_ip_address'
  app/controllers/application_controller.rb:491:in `set_current_admin'
  lib/gitlab/session.rb:11:in `with_session'
  app/controllers/application_controller.rb:482:in `set_session_storage'
  lib/gitlab/i18n.rb:73:in `with_locale'
  lib/gitlab/i18n.rb:79:in `with_user_locale'
  app/controllers/application_controller.rb:476:in `set_locale'
  lib/gitlab/error_tracking.rb:52:in `with_context'
  app/controllers/application_controller.rb:541:in `sentry_context'
  app/controllers/application_controller.rb:469:in `block in set_current_context'
  lib/gitlab/application_context.rb:52:in `block in use'
  lib/gitlab/application_context.rb:52:in `use'
  lib/gitlab/application_context.rb:20:in `with_context'
  app/controllers/application_controller.rb:462:in `set_current_context'
  lib/gitlab/metrics/elasticsearch_rack_middleware.rb:16:in `call'
  lib/gitlab/middleware/rails_queue_duration.rb:33:in `call'
  lib/gitlab/metrics/rack_middleware.rb:16:in `block in call'
  lib/gitlab/metrics/transaction.rb:61:in `run'
  lib/gitlab/metrics/rack_middleware.rb:16:in `call'
  lib/gitlab/request_profiler/middleware.rb:17:in `call'
  lib/gitlab/query_limiting/middleware.rb:17:in `block in call'
  lib/gitlab/query_limiting/transaction.rb:39:in `run'
  lib/gitlab/query_limiting/middleware.rb:16:in `call'
  lib/gitlab/jira/middleware.rb:19:in `call'
  lib/gitlab/middleware/go.rb:20:in `call'
  lib/gitlab/etag_caching/middleware.rb:13:in `call'
  lib/gitlab/middleware/multipart.rb:218:in `call'
  lib/gitlab/middleware/read_only/controller.rb:51:in `call'
  lib/gitlab/middleware/read_only.rb:18:in `call'
  lib/gitlab/middleware/same_site_cookies.rb:27: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:23:in `call'
  config/initializers/fix_local_cache_middleware.rb:9:in `call'
  lib/gitlab/middleware/static.rb:11:in `call'
  lib/gitlab/webpack/dev_server_middleware.rb:27:in `perform_request'
  lib/gitlab/metrics/requests_rack_middleware.rb:60:in `call'
  lib/gitlab/middleware/release_env.rb:12:in `call'

Output of checks

GitLab.com

Possible fixes

A fix could be to set the value of the issue_type to the default value from the Issue model when an invalid issue type is provided. This could be done in the 'issue_create_params' function at app/controlers/projects/issues_controller.rb#L301-309