Problem

Interactive PONS requests also need TM matches to be available before PONS is called - the editor match panel is the second path (besides batch analysis) on which PONS must receive TM context.

Today no ordering exists and none can easily be added where the requests originate: when a segment is opened, the frontend fires one independent HTTP request per assigned language resource in a tight loop (MatchGridViewController.js:130-216, Ext.Ajax.request per resource against {{languageresourceinstance/

/query}}), all in parallel, results rendering incrementally as they arrive. The backend handles strictly one resource per request (LanguageresourceinstanceController::queryAction, :1809-1886) and never sees the set of assigned resources, so a server-side reordering of "the pipeline" is impossible there, and a frontend reordering would require cross-request coordination, deadline handling and passing TM match data through the client.

Solution

Implement the required pipeline server-side, inside the request of the context-aware resource, using the injection architecture (no loosely defined optional connector arguments, no frontend changes):

When the editor queries a resource implementing SupportsTmContext (e.g. PONS), the context orchestrator in the generic _query() funnel:

1. Queries the task's assigned TM resources live (existing t5memory interactive search, current segment only)
2. Collects and normalises the matches into TmMatch entries (similarity, source, target), applying the provider filters (minimum similarity, max matches)
3. Creates a TmContext for the current segment
4. Injects it into the connector via setTmContext()
5. Only then is the resource itself queried

So TM resources are queried first within that request; PONS receives the TM context before it is queried. The editor path deliberately queries live instead of reading the analysis-time batch cache: TMs are written during the workflow (segments saved on confirm), so cached matches can be outdated - the interactive pipeline must reflect the current TM state.

Resources without context support are completely unaffected (the orchestrator only acts on the capability interfaces), and the match panel display stays exactly as it is - each resource still answers its own request, results render incrementally and are sorted by matchrate as today.

Errors and timeouts follow a defined fallback rule: each context TM query runs with its own short timeout (config, default 5 s); a failing or slow TM is skipped and logged, the context contains the matches gathered so far (possibly empty), and the context-aware resource is always queried - a TM outage degrades the context, it never blocks the match panel.

The TM queries for context run inside the PONS request and are additional to the panel's own TM display requests; t5memory queries are fast and the additional load is one query per assigned TM per context-aware resource request.