Wrote a few comments on the Merge Request!

I am moving this task as part of my Clinic Duty rotation.

@HCoplin-WMF , may you look at this task along with the thread that @daniel tagged you in, with @MHorsey-WMF , Moriel, and Alex, to let us know your thoughts?

I am moving this task as part of my Clinic Duty rotation.

@aaron is tagged as reviewer on the patch.

I am moving this task as part of my Clinic Duty rotation. @cscott , may you share more about the urgency of this task? I see that T436417: Extend JsonCodec to handle services (JsonCodecableWithServices) already has merged patches for creating the JsonCodecableWithServices trait.

Thank you for reporting this behavior, @Mvolz . I am moving this task as part of my Clinic Duty rotation.

I am moving this task as part of my Clinic Duty rotation.

I am moving this task as part of my Clinic Duty rotation because Merge history shows as unowned (https://www.mediawiki.org/wiki/Wikimedia_Production/Service_Catalog).

I am moving this task as part of my Clinic Duty rotation because the Content Platform team owns Parsoid and Language Converter (https://www.mediawiki.org/wiki/Wikimedia_Production/Service_Catalog).

I am moving this task as part of my Clinic Duty rotation.

I am moving this task as part of my Clinic Duty rotation.

1. Change 1333145 (active approach): Place module base and spec URL resolution in Router (Router::getModuleBaseUrl() and Router::getModuleSpecUrl()) to reuse Router::getRouteUrl() and keep ModuleInfo a pure value object. Change-Id: I7695d3
   1. Change 1341112 (alternative approach): Inject UrlUtils and $wgCanonicalServer into ModuleManager to pre-render absolute URLs upfront on ModuleInfo (getAbsoluteBaseUrl() and getAbsoluteSpecUrl()), eliminating the need for handlers to call Router for these URLs.

In T436570#12302632, @HCoplin-WMF wrote:

Adding to API Platform sprint board so we can do a light code review for the new API module. @KineticPelagic -- since it looks like you're on chore duty today, could you take a look?

I am moving this task as part of my Clinic Duty rotation.

As part of my Clinic Duty rotation, I am moving this spike so that the team can talk about it in refinement.

In T426852#12243441, @ArielGlenn wrote:

• @KineticPelagic you wanted an example of a graceful fallback for external module maintainers who serve their OpenAPI spec from somewhere else. We need to do some testing with an early adopter to see what is reasonable for this. Currently there are no requirements at all afaict.

Thanks, @AGhirelli-WMF . I concur with your diagnosis.

Implementation note: During the review of a REST vNext patch to encapsulate module configuration and management for T433516: REST vNext: ModuleManager should encapsulate module configuration, @AGhirelli-WMF and I identified a design quirk that this task can address as part of the implementation.

Sounds interesting for our team to discuss. I am moving this task as part of my Clinic Duty rotation.

I am moving this task as part of my Clinic Duty rotation.

In T429399#12216790, @HCoplin-WMF wrote:

1. I agree that a group should always be assigned.
2. Default works for now.

Note: Please address this request in the implementation of this task.

@HCoplin-WMF , I have two questions for you, arising from a code review comment from @daniel .

@aaron , would like your help triaging this one.

Moving the task as part of my Clinic Duty rotation. Let's discuss as a team.

@HCoplin-WMF , should we bring this request up with Tech Docs?

@HCoplin-WMF , should we bring this request up with Tech Docs?

Moving as part of my Clinic Duty rotation. I gave +1 on the patch.

Moving to Radar because another team has prioritized this task under FY2026-2027 OKR ST6.4: Strengthening & Risk Mitigation of the Platform - Logged-in readership.

As part of my Clinic Duty rotation, I am moving this task to Bugs & Chores, modeling this decision.

As part of my Clinic Duty rotation, I am moving this task to Bugs & Chores, modeling this decision.

I additionally included: In the configuration for REST external modules, add a '+wikipedia' override, which has the caution message in the OpenAPI spec info header.

Thank you for the update and the huge progress, @TBurmeister ! Thank you for the reviews, @AGhirelli-WMF and @KBach !

In T429399#12168182, @daniel wrote:

I filed T429399: Audience designations or groups are explicitly included in the discovery endpoint response to clarify how groups should be derived. @KineticPelagic that can be addressed as a follow-up, it doesn't have to affect your current patch much. But perhaps it would be useful to already declare "groups" as a list of strings on the module entry in the discovery document.

In T408816#12169685, @ArielGlenn wrote:

In reply to an implied question in the task description:

There is a test-commons.wikimedia.org and a test.wikipedia.org but no other test projects. The test-commons project is intended to go away "Soon", whatever that means.