I also did spot some CPU spikes for the sql workloads, not only but also at the same time where this error occured:

I started a bit on this but couldnt get very far as I struggled with letting the ui point the local docker api https://github.com/wbstack/ui/pull/1154

tests on staging:

0 15:42 » deer@wmde-102295 ~
 $ curl -Ls https://www.wikibase.dev/api/v1/policies/terms-of-use | jq
{
  "items": [
    {
      "metadata": {
        "policy_id": 3,
        "type": "terms-of-use",
        "active_from": null,
        "content_vue_file": "terms-of-use/version-2.vue"
      }
    },
    {
      "metadata": {
        "policy_id": 1,
        "type": "terms-of-use",
        "active_from": "2022-01-01",
        "content_vue_file": "terms-of-use/version-1.vue"
      }
    }
  ]
}
0 15:42 » deer@wmde-102295 ~
 $ curl -Ls https://www.wikibase.dev/api/v1/policies/terms-of-use/current | jq
{
  "metadata": {
    "policy_id": 1,
    "type": "terms-of-use",
    "active_from": "2022-01-01",
    "content_vue_file": "terms-of-use/version-1.vue"
  }
}
0 15:42 » deer@wmde-102295 ~
 $ curl -Ls https://www.wikibase.dev/api/v1/policies/terms-of-use/upcoming | jq
{
  "metadata": {
    "policy_id": 3,
    "type": "terms-of-use",
    "active_from": null,
    "content_vue_file": "terms-of-use/version-2.vue"
  }
}

found a bug while trying this on staging; reverted.

Just now I was wondering if the GET /v1/policies/{policy_type} endpoint should also contain upcoming policies - as per the example from the senior notes doc it seems the answer is "yes":

Two observations:

I paired with @Tarrow on this and we said that for this ticket we scope it on ToU routes like /terms-of-use/:active_from, while keeping the current handling of /terms-of-use/ and /terms-of-use/upcoming until we have the endpoints from T432714: 📜P1: make remaining GET endpoints for upcoming, current and all policies of a given type

live test for production:

$ curl -Ls https://wikibase.cloud/api/v1/policies/current | jq
{
  "items": [
    {
      "metadata": {
        "policy_id": 1,
        "type": "terms-of-use",
        "active_from": "2022-01-01",
        "content_vue_file": "terms-of-use/version-1.vue"
      }
    }
  ]
}

live test for staging:

$ curl -Ls https://wikibase.dev/api/v1/policies/current | jq
{
  "items": [
    {
      "metadata": {
        "policy_id": 1,
        "type": "terms-of-use",
        "active_from": "2022-01-01",
        "content_vue_file": "terms-of-use/version-1.vue"
      }
    },
    {
      "metadata": {
        "policy_id": 2,
        "type": "hosting-policy",
        "active_from": "2026-07-01",
        "content_vue_file": "hosting-policy/version-1.vue"
      }
    }
  ]
}

@dang @Rosalie_WMDE I brought this data shape topic up in the seniors round; Seems like a lot of thought already went into this endpoint spec and it was clarified that we should stick to the example in the ticket. Sorry for leading you off in another direction.

Flagging it here that it's debatable if returning this as an items object is the right choice here, as per default it seems to get wrapped in a generic data object anyway and I couldn't find any previous use of items notation in this API.
See https://github.com/wbstack/api/pull/1198/changes#r3572344840

I still think we should do this - as previously suggested in the old PR[1] I assess the risk of accidentally excluding a working patch, and thereby breaking something, higher than deploying an incompatible patch.

did some more work on the PR today + added some test coverage

created companion PR to update .tool-versions file https://github.com/wmde/wbaas-deploy/pull/2886

I created this merge branch ui_tou_merge that combines the navigation panel workstream (this task; #1140) and the upcoming ToU workstream (T420575, #1130)

The PR is not finished yet but ready for it's first round of review, regarding the NavigationPanel component structure.

If requesting JSON by HTTP header we get JSON in return:

$ curl -sS -H 'Accept: application/json' "https://www.wikibase.dev/api/wiki?per_page=101" | jq
{
  "message": "The per page must not be greater than 100.",
  "errors": {
    "per_page": [
      "The per page must not be greater than 100."
    ]
  }
}

I think you are probably right but I would imagine this is actually a left over artefact from running the tests locally rather than an explicit desire to have each test run output data for this one test.

@Alice.moutinho ah good catch, thanks! I adjusted it, (same preview link): https://ee938e4af3-prod--wbstack-ui.netlify.app/dsa-info

Is there some more context to this? Generally this looks like good practice of course but I assume the reason the output in the integration test was added is to help gather information for debugging purposes of the rather complex component setup (i.e. having the data from successful tests may be useful to compare to eventually failed tests)

This got unblocked now and is ready from engineer perspective

for Product and UX: current state can be previewed here: https://ee938e4af3-prod--wbstack-ui.netlify.app/dsa-info

blocked by T428389: Fix e2e tests in Platform UI CI