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.

On a side note, should these wikibase dumps be running under the airflow-wmde or airflow-wikidata instances, where you might be able to interact with them more fully?

The Wikidata Platform, Data Platform SRE, and WMDE teams met to discuss this question and aligned that there should not be any change to the current data dump ownership. WMDE, as owners of Wikibase, will continue to own and escalate issues to Data Platform SREs where needed.

Summary of discussion test servers:

• WMCS is not an option according to @gmodena (we can't get enough RAM in a single VM)
• AWS is a path that everyone seems to be happy with. @gmodena will work with @LSobanski to get this moving, DPE SRE will not be involved (unless WDP requires support)
• Once we are somewhat confident with what solution we will use, we can move to testing on prem. We may use test servers in the current WDQS pool or the spare pool (if the specs are OK). TBD on first round of testing.
• To go to production, we may need new servers. TBD on testing.

The graph split has been completed and findings are available on the WDQS backend update page. Resolving issue.

I have access now, thanks @Dzahn !

When trying to access https://superset.wikimedia.org, I'm receiving the error message "Service access denied due to missing privileges." Attaching a screenshot for reference.

One option we considered but rapidly discarded is doing a full reconcilation of all entities over a long period of time. At one reconciliation per second it would take ~3.17 years to reconcile, increasing the rate might not be acceptable given the cost of these reconciliations.

The outage has been resolved. Moving tracking of the incident to the incident report.

I've read the guidelines and updated this request to reflect. Thanks, again.

That sounds like the right path forward. Thank you!

Specifically, I don't think "most clients don't support setting a user-agent" as an unsurmountable problem client-side. I would expect this exception to be lifted at the start of 2026; if you want more time, then I think this needs a discussion. For now I'll clearly indicate this and other exceptions will be removed at the start of 2026 unless an extension is negotiated.

The Wikidata Platform team was just staffed in August and is taking over ownership of the Wikidata Query Service Phabricator project from the Search Platform team. We - myself and our Tech Lead, @gmodena - would like to join acl*Project-Admins so we can use Phabricator to manage that project. Specifically, we need access to planning features, such as the creation of Milestones and Subprojects for work/sprint tracking. Without the proper permissions, we have a dependency on the Search Platform team to create these views for us. We have aligned with @Gehel and team on transferring the project.

We won't be able to work on this request in the near future (1-2 months). The utility of a journal file is tied to the use of Blazegraph, which we are currently evaluating alternatives for. Until we have more clarity on next steps for an architectural migration, we can't commit to feature requests like these.

Thanks @Addshore for bringing to our attention and @Gehel for flagging to the team. Moving this ticket to feature requests and will evaluate in the coming sprints.

Thanks, @CDanis. We will follow up on the user-agent exception once the team has had a chance to align internally.