### Summary Creating an issue fails with HTTP 500 (`TypeError: no implicit conversion of Symbol into Integer` from `app/services/concerns/work_items/widgetable_service.rb:18`) when the create request includes the custom-fields widget input (even an **empty array**) and the description contains a type-changing quick action such as `/promote_to_incident`. This is the **creation-path variant of the bug fixed in !234808** ("Fix CustomFields callback crashing during work item type change", 19.0). That fix guards the callback's `after_save`, but at creation time `initialize_callbacks!` crashes at line 18 — before any callback runs — so the guard never engages. Reproduced on GitLab.com production (2026-08-26). ### Steps to reproduce In any project whose namespace has the custom-fields widget license-available (Ultimate group — **no custom fields need to be configured**), run: ```graphql mutation { workItemCreate(input: { projectPath: "<project in an Ultimate group>", title: "repro", workItemTypeId: "gid://gitlab/WorkItems::Type/1", descriptionWidget: { description: "/promote_to_incident" }, customFieldsWidget: [] }) { workItem { id } errors } } ``` Result: `Internal server error`. The identical mutation **without** `customFieldsWidget` succeeds and correctly promotes the new work item to an Incident (verified as a control). Notes: - Personal namespaces cannot reproduce: the mutation rejects the argument with "Following widget keys are not supported by Issue type". - On GitLab 19.1.x, the work-items "New issue" form sends `customFieldsWidget: []` unconditionally whenever the widget is license-available, so on affected versions this fires from the plain web UI when using a description template containing `/promote_to_incident` — no API involvement. The `customFieldsWidget` argument is deprecated, which may mask the bug in GitLab.com's current UI while it remains API-triggerable in production. ### What happens HTTP 500. Backtrace (top frames, from a 19.1.4-ee instance; implicated code is identical through current master): ``` TypeError: no implicit conversion of Symbol into Integer app/services/concerns/work_items/widgetable_service.rb:18:in '[]=' app/services/concerns/work_items/widgetable_service.rb:18:in 'block in initialize_callbacks!' app/services/concerns/work_items/widgetable_service.rb:13:in 'filter_map' app/services/concerns/work_items/widgetable_service.rb:13:in 'initialize_callbacks!' app/services/issuable_base_service.rb:228:in 'create' ee/app/services/ee/issues/create_service.rb:16:in 'create' app/services/issues/create_service.rb:39:in 'execute' app/services/concerns/rate_limited_service.rb:84:in 'execute' app/services/work_items/create_service.rb:20:in 'execute' ee/app/services/ee/work_items/create_service.rb:15:in 'execute' app/graphql/mutations/work_items/create.rb:123:in 'resolve' ee/app/graphql/ee/mutations/work_items/create.rb:54:in 'resolve' ``` ### What is expected The work item is created with the type change applied and the custom-fields input for the (now excluded) widget dropped — matching `/promote_to_incident` behavior on existing issues, which works correctly. ### Analysis The failing line (identical on `v19.1.4-ee`, `v19.2.4-ee`, and current master): ```ruby callback_params = widget_params[widget.class.api_symbol] || {} callback_params[:excluded_in_new_type] = true if new_type_excludes_widget?(widget, work_item.resource_parent) # line 18 ``` The custom-fields widget is the only widget whose params are an **Array** (of `{custom_field_id:, ...}` hashes) rather than a Hash. When a type-changing quick action makes `new_type_excludes_widget?` true for it (Incident does not include the custom_fields widget), line 18 performs a Symbol-keyed assignment on that Array and `Array#[]=` raises `TypeError`. An empty array is sufficient: `[] || {}` keeps the array, and `[]` is not `blank?`-guarded before the mutation on line 18. As !234808 noted, the same applies to any source/target type pair where the source has custom_fields and the target does not (`/convert_to_ticket`, `/type`); the difference here is that on the creation path the exception is thrown while building the callbacks, so the `excluded_in_new_type?` guard added to the callback class in 19.0 cannot help. A shape-aware fix at line 18 (or normalizing/dropping non-Hash widget params for excluded widgets) would cover both paths. ### Versions / environment - Originally hit on GitLab 19.1.4-ee (GitLab Dedicated, Ultimate) from the plain web UI via a description template; confirmed via `graphql_json` logs that the frontend sent `customFieldsWidget: []` with zero custom fields configured. - Reproduced on GitLab.com production (2026-08-26) via GraphQL as above. - `app/services/concerns/work_items/widgetable_service.rb` is byte-identical on `v19.1.4-ee`, `v19.2.4-ee`, and current master. ### Workaround Create the issue without the template (title only), then add the description afterwards; `/promote_to_incident` on the existing issue works correctly.