The LDF endpoint is scheduled to be decommissioned on February 18th, 2026 (see T415696). This ticket can be closed once the endpoint is disabled.

Thanks @Gehel. Knowing that the work is not complicated and that Monday, February 16th is a US holiday, we will plan on Wednesday, February 18th for the change. I'll update this ticket again closer to the date to confirm.

Looks great. Please feel free to check acceptance criteria as they are addressed.

Thanks, @Joe . We're firmly committed to Feb 18th.

Hi @Pfps , the topics on the backend update page are being responded to now. Apologies for missing them - there was a large amount of ownership handoff of documentation when our new team started and subscribing to this page to listen for comments from the community got lost in the shuffle. We are listening to the page now to ensure it can reliably serve as the central hub for updates we denoted it as.

The new date for completing this request is January 20th. @Gehel please advise if you want me to update the description to reflect.

We are postponing the decommissioning of the wdqs2009 endpoint.

Thanks, @Bluerasberry. Acknowledging the dependency on T413097 from the WDP side, as well. Unfortunately, we likely won't have the necessary inputs to prioritize that request before the end of the 2025.

Hi @CDanis , we recently finalized a decision brief on next steps for this issue. We aligned upon revoking the exception and working with WDQS users to ensure their federated queries are compliant with the UA policy. To ensure we have enough lead time to communicate the upcoming change, we are requesting that the policy exception remain in place until February 18th, 2026.

+1. My only concern would be that extending the threshold for alarms would only extend the delay between SREs being alerted and the incident. However, it appears that many lag issues self-resolve (grafana) so I'm aligned with the change.

Resolving this request and tracking the remaining open questions on T375592

@Pfps we have submitted a request to safety and security and are waiting on a response before proceeding. We are still targeting 11/21, but this date is tentative as we work through the correct process.

Hi @Pfps - we are coordinating with the WMF safety and security team on how they advise we share this data. We expect to have guidance from them and next steps on this request by the end of next week (11/21).

Elevating this request to High Priority. The inconsistent timestamp generated in DAG is breaking filesystem downstream by producing unexpected dates. This has caused failures to the data dump process via a WMF airflow over the last 4 weeks, and means that a rebuild of WDQS would depend on outdated data.

Resolving as behavior during our testing was as expected. Please see comments on this thread for handling expensive or complex queries through different data access points.