fix(logging): register the operation REST filter param

[i-anubhav-anand]

What?

Registers the operation query parameter on the AI Request Log REST endpoint (/ai/v1/logs).

operation is read and applied as a filter server-side and is sent by the Request Log admin UI, but it was the only filter parameter missing from AI_Request_Log_Controller::get_collection_params().

Why?

Because the parameter was unregistered:

1. It bypassed the REST framework's argument validation. The repository parses it as a comma-separated string:

   // includes/Logging/AI_Request_Log_Repository.php
   $operations = array_filter( array_map( 'trim', explode( ',', $args['operation'] ) ) );

   The admin UI always sends a string (operations.join(',')), but the public endpoint accepts whatever a client sends. A non-string value reaches explode() and raises a fatal:

   GET /ai/v1/logs?operation[]=openai:completions&operation[]=google:generateContent
   → TypeError: explode(): Argument #2 ($string) must be of type string, array given
     at includes/Logging/AI_Request_Log_Repository.php:475   (HTTP 500)
   

2. It was missing from the REST schema, so API consumers couldn't discover it via schema introspection — unlike every sibling filter (type, status, provider, search, …).

How?

Add operation to get_collection_params() as a string parameter, matching the documented comma-separated contract. WordPress then validates the type before the value reaches the repository (a non-string value is rejected with a 400 instead of fataling), and the parameter is now part of the endpoint schema.

'operation' => array(
    'description' => __( 'Filter by operation. Accepts a single value or a comma-separated list.', 'ai' ),
    'type'        => 'string',
    'default'     => '',
),

This is a one-parameter, surgical change; no behavior changes for the existing (string) filter path.

Use of AI Tools

AI assistance: Yes
Tool(s): AI coding assistant (agentic CLI)
Used for: auditing the REST controller/repository, reproducing the bug, and drafting the fix + tests. All code was written test-first, executed, and reviewed by me; I take responsibility for it.

Testing Instructions

npm run wp-env:test start
npm run test:php -- --filter AI_Request_Log_ControllerTest

Added/extended tests in tests/Integration/Includes/Logging/AI_Request_Log_ControllerTest.php:

• test_get_collection_params_returns_expected_keys — now also asserts operation is a registered param.
• test_get_logs_filters_by_operation — the filter returns only matching rows (baseline; passes before and after).
• test_get_logs_rejects_non_string_operation — an array operation value is handled with a 400 rather than a fatal.

Fail-before / pass-after (source registration reverted, tests kept):

# before:
1) ...::test_get_collection_params_returns_expected_keys
Failed asserting that an array has the key 'operation'.

2) ...::test_get_logs_rejects_non_string_operation
TypeError: explode(): Argument #2 ($string) must be of type string, array given
   at includes/Logging/AI_Request_Log_Repository.php:475

# after:
OK (3 tests, 22 assertions)

Full Logging suite is green (122 tests); full integration suite is green (840 tests, 34 pre-existing skips).

Changelog Entry

Fixed - The AI Request Log REST endpoint now registers its operation filter parameter, so it appears in the REST schema and a non-string value returns a 400 instead of causing a fatal error.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: i-anubhav-anand <anubhav24@git.wordpress.org>
Co-authored-by: dkotter <dkotter@git.wordpress.org>
Co-authored-by: jeffpaul <jeffpaul@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.44%. Comparing base (656fbde) to head (4acfb53).

Additional details and impacted files

@@              Coverage Diff              @@
##             develop     #758      +/-   ##
=============================================
+ Coverage      78.43%   78.44%   +0.01%     
  Complexity      2454     2454              
=============================================
  Files            104      104              
  Lines           9920     9925       +5     
=============================================
+ Hits            7781     7786       +5     
  Misses          2139     2139              

Flag	Coverage Δ
unit	78.44% <100.00%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jeffpaul]

@i-anubhav-anand is this still in progress or can it come out of draft for review?

[jeffpaul]

@i-anubhav-anand checking back to see if this is still in progress or ready for review?

[i-anubhav-anand]

Thanks for checking in @jeffpaul — this one is code-complete, it was just left in draft. Marking it ready for review now.

For reference: the operation filter param is registered in AI_Request_Log_Controller::get_collection_params() (type string, matching the documented comma-separated contract), which both adds it to the REST schema and lets WordPress reject a non-string value with a 400 before it reaches the explode() in AI_Request_Log_Repository (previously a fatal TypeError). Coverage is green and the three tests described above cover the schema registration, the filter behaviour, and the non-string rejection path.