Filter action-based links from MCP work package responses

[NobodysNightmare]

These links don't offer any helpful context for understanding the work package better, but they increase the size of the response significantly.

In our HAL/Hateoas-based APIv3 they are used to communicate what can happen to a resource. However, MCP clients will usually try to do what users ask them to do and then see if that succeeds, rather than assuming that a certain action is not possible because a corresponding link is missing. Thus those "action links" are mostly dead weight in the response.

Ticket

https://community.openproject.org/wp/AI-45

Impact

I am trying to gauge the impact of this change (including the upstream change of filtering HTML).

In our search_work_package test case that returns two work packages, the response size on dev is ~22kB, while the size on this PR is just shy of 12kB. This means a reduction in response size of about 45%.

I also did another test with one of my local test work packages. It might over-use wiki page links a bit, so also take that with a grain of salt, but here the reduction is more impactful, shrinking the response from 28.48 kiB to 4.22 kiB, so a reduction by 85%.

For reference, this is the work package:

[github-actions]

Caution

The provided work package version does not match the core version

Details:

• Work package URL: https://community.openproject.org/wp/AI-45
• Work package version: 17.8.0
• Core version: 17.7.0

Please make sure that:

• The work package version OR your pull request target branch is correct

[NobodysNightmare]

This is a pretty manual approach to filtering links...

I am wondering whether this is acceptable, as the topic of filtering these is kind of a micro optimization for MCP alone or whether it would be worth to invest more into the architecture here.

For example we could classify the links at definition time (i.e. in the representer class) and then reflect based on that classification whether we should filter them or not. On the plus side, this would allow to define one filter that works across different resources. On the minus side, this is vastly more complex and cross-cutting, while only solving a "local" MCP problem.

Thoughts and opinions on that?

[github-actions]

Warning

Flaky specs

• rspec ./spec/features/types/subtypes_index_spec.rb[1:5]

🤖 Ask Copilot to investigate

Copy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer.

@copilot The following spec(s) are flaky in CI (first seen on PR #24307, linked for reference only):

- `rspec ./spec/features/types/subtypes_index_spec.rb[1:5]`

Treat this as a standalone task, unrelated to PR #24307. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #24307 or reuse that branch.

Follow the playbook in docs/development/testing/handling-flaky-tests/README.md to find the root cause and fix the underlying race — do not skip, delete, or weaken the spec to make it pass; disabling is a last resort per the playbook, and only with a bug ticket. Verify the fix by running the spec(s) repeatedly (e.g. `script/bulk_run_rspec --run-count 10`).

If you cannot reproduce the flake or are not confident in a fix after reasonable investigation, do not fabricate a change or skip the spec to force CI green. Instead, leave the pull request in draft and document what you tried, the suspected cause, and any leads in its description, then assign @NobodysNightmare to take over.

Once the fix is verified, title the PR after the spec(s) it fixes, and use the PR description to explain the root cause, how the change resolves it, and the before/after results. Label the PR `flaky-spec`, assign @NobodysNightmare, and request a review from @NobodysNightmare.
On every commit, set @NobodysNightmare as the sole co-author with a `Co-authored-by:` trailer (use their GitHub no-reply email so it links to their account), so it is traceable who dispatched the fix.

[github-actions]

Warning

Flaky specs

• rspec ./spec/features/forums/message_spec.rb[1:1]
• rspec ./spec/features/types/subtypes_index_spec.rb[1:5]

🤖 Ask Copilot to investigate

Copy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer.

@copilot The following spec(s) are flaky in CI (first seen on PR #24307, linked for reference only):

- `rspec ./spec/features/forums/message_spec.rb[1:1]`
- `rspec ./spec/features/types/subtypes_index_spec.rb[1:5]`

Treat this as a standalone task, unrelated to PR #24307. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #24307 or reuse that branch.

Follow the playbook in docs/development/testing/handling-flaky-tests/README.md to find the root cause and fix the underlying race — do not skip, delete, or weaken the spec to make it pass; disabling is a last resort per the playbook, and only with a bug ticket. Verify the fix by running the spec(s) repeatedly (e.g. `script/bulk_run_rspec --run-count 10`).

If you cannot reproduce the flake or are not confident in a fix after reasonable investigation, do not fabricate a change or skip the spec to force CI green. Instead, leave the pull request in draft and document what you tried, the suspected cause, and any leads in its description, then assign @NobodysNightmare to take over.

Once the fix is verified, title the PR after the spec(s) it fixes, and use the PR description to explain the root cause, how the change resolves it, and the before/after results. Label the PR `flaky-spec`, assign @NobodysNightmare, and request a review from @NobodysNightmare.
On every commit, set @NobodysNightmare as the sole co-author with a `Co-authored-by:` trailer (use their GitHub no-reply email so it links to their account), so it is traceable who dispatched the fix.