What does this MR do and why?

This MR optimizes the feature spec ee/spec/features/work_items/epics/epic_work_item_detail_spec.rb to reduce its execution time from ~23 minutes to approximately 12–15 minutes.

The spec was suffering from significant performance bottlenecks due to:

• Redundant Browser Resizing: The browser window was being resized in a before block, triggering an expensive layout recalculation for every single test and shared example (20+ times).

• Expensive Data Setup: Using standard let and let_it_be_with_refind for complex Work Items and Users forced unnecessary database lookups and object recreations for every test.

• App Reloads: The use of page.refresh in the hierarchy tests forced the entire Vue application to reload, which is extremely slow in a JS-enabled environment.

References

Screenshots or screen recordings

How to set up and validate locally

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #589698

Ashok Pelluru (4b046f47) at 17 Mar 12:20

... and 5 more commits

Ashok Pelluru (e8420ced) at 16 Mar 13:27

... and 1471 more commits

Hey @daphchi , please take a look at this MR: !227082

Ashok Pelluru (1b061a40) at 13 Mar 11:05

Ashok Pelluru (22591d84) at 13 Mar 10:59

What does this MR do and why?

This MR adds a new field labels_text to the object_attributes hash in the webhook payloads for both Issues and Merge Requests. This field provides a comma-separated string of label titles (e.g., "bug, feature, backend"

Why is it needed?

Third-party automation tools, such as Slack Workflow Builder, often lack the logic to iterate through JSON arrays (the existing labels array). By providing a pre-formatted string in labels_text, users can map labels directly to Slack messages or other low-code platforms without requiring an intermediate middleware or "glue" service.

References

Screenshots or screen recordings

How to set up and validate locally

• Configure a Webhook for "Issue events" or "Merge Request events" on a project.

• Create or update an issue/MR and add several labels.

• Inspect the webhook payload (e.g., using a tool like Webhook.site or the GitLab Webhook logs).

• Confirm that object_attributes contains:

"labels_text": "label1, label2, label3"

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #592823

Ashok Pelluru (e01d9153) at 12 Mar 14:24

Hi @daphchi

I would recommend the option 1,

because Adding a pre-computed string to the JSON payload is a "set it and forget it" fix. It doesn't require complex logic and the data is simply there and ready to use.

Generating a comma-separated string during the serialization phase is computationally cheap. It avoids forcing the user to write complex Liquid or Handlebars logic (which GitLab’s current webhook implementation doesn't fully support for deep object manipulation anyway).

Adding a new key like labels_text doesn't break existing integrations that rely on the labels array. It’s purely additive.

Please let me know your thoughts and would like to contribute.

please also provide me some insights to understand the existing logic and keypoints to focus.

Cheers, Ashok

Hi @msaleiko,

Greetings from Mülheim an der Ruhr! 😄

Thank you for providing such detailed insights; they are incredibly helpful for the community's understanding of the backend.

I’ll wait for MR1 to be merged before continuing my work on this ticket.

Best regards,

Ashok

Ashok Pelluru (6ddacef9) at 10 Mar 11:31

Ashok Pelluru (3ad0cb63) at 10 Mar 10:59

Hi @msaleiko Can community member contribute into this?

If so, here is drafted MR version, and will continue to add the tech documentation as well.

!226637

What does this MR do and why?

This MR introduces the work_item_type_ids parameter to both the Issues API (lib/api/issues.rb) and the Work Items API (lib/api/work_items.rb), allowing users to filter records using Global IDs (GIDs).

Key implementations:

• API Exposure: Adds work_item_type_ids to the permitted parameters, including support inside the negated not hash.

• Flexible Formatting: Supports both array formats (?work_item_type_ids[]=gid1&work_item_type_ids[]=gid2) and comma-separated strings (?work_item_type_ids=gid1,gid2)

• Secure GID Parsing: Uses GlobalID.parse to extract the underlying database integer IDs, silently ignoring gracefully degrading any malformed or invalid GIDs.

• Finder Compatibility: Bridges the gap between API GIDs and internal Finders by mapping the parsed IDs to their human-readable base_type strings (e.g., ["issue", "task"]) via a new WorkItems::Type.base_types_for_ids model method. This ensures IssuesFinder and WorkItemsFinder behave as expected without requiring deep architectural changes.

• Validation: Implements Grape mutually_exclusive checks to prevent users from mixing the legacy issue_type/types parameters with the new work_item_type_ids parameter.

• Testing: Provides full RSpec coverage for both endpoints, validating coercion, negated filters, N+1 query safety, and mutual exclusivity errors.

Part of #582561.

References

Screenshots or screen recordings

How to set up and validate locally

1. Test 1: Filter Work Items by Type GID (Note: gid://gitlab/WorkItems::Type/1 is the standard GID for an Issue, 2 is Incident, 5 is Task):

curl --header "PRIVATE-TOKEN: $GITLAB_TOKEN" \
  "http://127.0.0.1:3000/api/v4/projects/$PROJECT_ID/-/work_items?work_item_type_ids=gid://gitlab/WorkItems::Type/1"

2. Comma-separated multiple GIDs

 curl --header "PRIVATE-TOKEN: $GITLAB_TOKEN" \
  "http://127.0.0.1:3000/api/v4/projects/$PROJECT_ID/-/work_items?work_item_type_ids=gid://gitlab/WorkItems::Type/1,gid://gitlab/WorkItems::Type/5"

3. Negated filtering on the Issues API

 curl --header "PRIVATE-TOKEN: $GITLAB_TOKEN" \
  "http://127.0.0.1:3000/api/v4/issues?not[work_item_type_ids]=gid://gitlab/WorkItems::Type/1"

4. Mutual Exclusivity Error Expected: Returns a 400 Bad Request stating issue_type, work_item_type_ids are mutually exclusive

 curl --header "PRIVATE-TOKEN: $GITLAB_TOKEN" \
  "http://127.0.0.1:3000/api/v4/issues?issue_type=incident&work_item_type_ids=gid://gitlab/WorkItems::Type/1"

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #592877

Ashok Pelluru (c28cf967) at 10 Mar 10:02

... and 26 more commits

@aalakkad thanks for your time and feedback. I have fixed them. Thank you

Ashok Pelluru (9d4dd676) at 06 Mar 12:53

... and 4119 more commits

Ashok Pelluru (013ff2e0) at 06 Mar 12:51

Hi @mfanGitLab looks like all the jobs failed during uploading artifacts, is it known issue?

Ashok Pelluru (cc86b35e) at 17 Feb 12:10

... and 1208 more commits