Summary: certain endpoints currently handled by RESTbase should be rerouted to equivalent MediaWiki REST endpoints. This will unblock this portion of RESTbase sunset. It is expected that callers will eventually be moved to new canonical urls, allowing these paths to be completely retired. However, new urls have not yet been defined. Implementing new urls and moving callers will take at least months, if not longer. See T366835: REST: API modularization and versioning (tracking) for related discussion.
Mapping of production URLs to be routed to MediaWiki-REST-API
Page and revision meta-data
- Get revision metadata for a title
- HTTP Verb: GET
- Production Endpoint:
- <domain>/api/rest_v1/page/title/{title}
- Example: https://en.wikipedia.org/api/rest_v1/page/title/Earth
- MW REST Endpoint:
- <domain>/w/rest.php/v1/page/{title}/bare
- Example: https://en.wikipedia.org/w/rest.php/v1/page/Earth/bare
- Get revision metadata for a title, by revision id
- HTTP Verb: GET
- Production Endpoint:
- <domain>/api/rest_v1/page/title/{title}/{revision}
- Example: https://en.wikipedia.org/api/rest_v1/page/title/Earth/1244226389
- MW REST Endpoint:
- <domain>/w/rest.php/v1/revision/{id}/bare
- Example: https://en.wikipedia.org/w/rest.php/v1/revision/1244226389/bare
- Notes:
- The {revision} parameter in the Production Endpoint corresponds to the {id} parameter in the MW REST Endpoint
- The {title} parameter in the Production Endpoint does not have an equivalent in the MW REST Endpoint
Rendered HTML
- Get latest HTML for a title.
- HTTP Verb: GET
- Production Endpoint:
- <domain>/api/rest_v1/page/html/{title}
- Example: https://en.wikipedia.org/api/rest_v1/page/html/Earth
- MW REST Endpoint:
- <domain>/w/rest.php/v1/page/{title}/html
- Example: https://en.wikipedia.org/w/rest.php/v1/page/Earth/html
- Get HTML for a specific title/revision & optionally timeuuid.
- HTTP Verb: GET
- Production Endpoint:
- <domain>/api/rest_v1/page/html/{title}/{revision}
- Example: https://en.wikipedia.org/api/rest_v1/page/html/Earth/1244226389
- MW REST Endpoint:
- <domain>/w/rest.php/v1/revision/{id}/html
- Example: https://en.wikipedia.org/w/rest.php/v1/revision/1244226389/html
- Notes:
- The {revision} parameter in the Production Endpoint corresponds to the {id} parameter in the MW REST Endpoint
- The {title} parameter in the Production Endpoint does not have an equivalent in the MW REST Endpoint
Additional Configuration:
All forwarded calls should include a x-restbase-compat header with a value of 'true'. This instructs the MW REST endpoints to return RESTbase-compatible data.
Acceptance Criteria
- This list is reviewed and approved by @MSantos, @HCoplin-WMF , and @daniel
- This list is reviewed and approved by ServiceOps (will tag them once the first review phase is complete)
- Endpoints are routed through REST Gateway
DetailsSubject Repo Branch Lines +/- gateway-check: Support (and use) per wiki rules mediawiki/core production +0 -3 Fixup for rest-gateway's request_headers_to_add operations/puppet production +3 -0 rest-gateway: Route page and html RESTBase routes to mw-api-int Comment ActionsYes, this is fine. The TID value designed as a transparent token. It can be used as a path parameter in future request, but that parameter has already been ignored for several months now.
Comment ActionsMost of my bots and tools that used RESTBase are now broken, and I suspect this is the cause based on timing. I expect there are probably 20-25 tools that are broken, and a similar number of bots across a number of wikis.
Here's the main error I'm seeing so far:
HTTP error: HTTP status client error (400 Bad Request) for url (https://en.wikipedia.org/w/rest.php/v1/page/Wikipedia%3AMiscellany_for_deletion%2FArchived_debates%2FNovember_2024/html?redirect=false)
Another error is these responses are no longer returning etags, which used to be guaranteed (and necessary!).
I haven't had the chance to track down further things yet and honestly it shouldn't be on me do this in an emergency mode, this is ridiculous. There's been literally no communication about this (which I pointed out back in T334238#10107841 in August), and when we've been proactive about asking for help, we've been met entirely with silence: T354037. I don't even know if this is feasible to revert, but the status quo isn't acceptable.
Edit: Just to add, bugs and regressions are fine, they happen, and that's unavoidable. The problem is not communicating about what is happening, especially when people are actively making an effort to be involved and literally help you. I want to get off RESTBase and have been trying to do that for months now and am stuck because people aren't communicating.
Comment ActionsChange #1087568 had a related patch set uploaded (by BPirkle; author: BPirkle):
[mediawiki/core@master] REST: Allow page endpoint "redirect" parameter to have value "false".
HCoplin-WMF added a comment.Nov 5 2024, 10:36 PM
Comment Actions@Legoktm -- this was 100% an unintended breakage that we are working to resolve as we speak. This change was supposed to be a clean reroute, with 0 impact to all API users. We will be rolling back the change imminently, while we create an updated PR to resolve the issue at its root. Sincere apologies for the accidental break, and we will get it resolved as soon as possible. Wholeheartedly agree that this should not be an emergency drill for you, as there should be no changes required on your side.
I also want to recognize and apologize for the slight delay in response and action since you flagged. It is election day in the US, so our engineers who are normally responding this time of day are out voting!
Comment ActionsChange #1087591 had a related patch set uploaded (by Arlolra; author: Arlolra):
[operations/puppet@production] Revert "Revert^2 "ats: Route rest_v1/page/(html|title) to rest-gateway""
Comment ActionsChange #1087591 merged by Ladsgroup:
[operations/puppet@production] Revert "Revert^2 "ats: Route rest_v1/page/(html|title) to rest-gateway""
Comment ActionsSounds good. I'll give the revert ~20 more minutes to roll out fully and report back to see if things are fixed.
This change was supposed to be a clean reroute, with 0 impact to all API users.
This is a reasonable goal, but I don't think it justfies the lack of communication. Shit happens, just let us know what to expect ahead of time. For example, if this was deployed to test.wikipedia.org first, our automated test suite would've run against it and caught it. Redirecting a big chunk of RESTBase over to rest.php is genuinely a big deal (as evidenced by how long it took to get here!!) and should be something people are shouting from the rooftops in celebration, not complaining about.
I also want to recognize and apologize for the slight delay in response and action since you flagged. It is election day in the US, so our engineers who are normally responding this time of day are out voting!
Makes sense, hopefully we can dig into this properly in the incident report (e.g. should U.S. election day be a no deploy day given low availability).
Comment ActionsBefore rolling out the switch again, it might be a good idea to survey all query parameters that are accepted for compatibility, if that hasn't been done already.
Moreover: do we have a set of urls that we've tested to work? It might be useful for us so that we can prepare an httpbb test suite to run before and after switching one host for validating the change.
Comment ActionsYes, I just double-checked - the only other supported query parameter is stash, which can be true or false.
Moreover: do we have a set of urls that we've tested to work? It might be useful for us so that we can prepare an httpbb test suite to run before and after switching one host for validating the change.
That would be nice, but it wouldn't have caught the problem we just encoutnered either - I wouldn't have thought to check for redirect=false. Known good cases are easy to cover, unknown bad cases are easy to miss...
Also, we may encounter problems that are more subtle - etag handling or cache control headers or CORS or whatnot. I checked all the stuff that I could think of a while ago, see
Comment ActionsThat all makes sense, but also now seems like the perfect time to encode a bunch of this lost-then-rediscovered knowledge into httpbb rules.
This is a
Comment ActionsThe responses were also not returning an etag header, as previously expected.
AFAIK redirect=false was always the canonical way to pass it (c.f. T130757#2184827). And like I said, this is all in the mwbot-rs test suite. Can you deploy to test.wikipedia.org first this time and give us like a week?
Also, we may encounter problems that are more subtle - etag handling or cache control headers or CORS or whatnot. I checked all the stuff that I could think of a while ago, see https://docs.google.com/spreadsheets/d/10FaxUcD6y4Xjss21HfXUwVsH98RCWO7Bs9hhZuDTfFg/edit?pli=1&gid=0#gid=0. But as we just found out, I didn't think of all the relevgant things to check...
This is a private spreadsheet.
Comment ActionsIt seems like this should be included in the next (or a near-future) Tech News edition.
Please could someone propose some wording/links for a Tech News entry? Please also confirm whether it should be in the upcoming edition (Frozen on Friday, sent on Monday), or the edition after that. Thanks.
https://docs.google.com/spreadsheets/d/10FaxUcD6y4Xjss21HfXUwVsH98RCWO7Bs9hhZuDTfFg/edit?pli=1&gid=0#gid=0. But as we just found out, I didn't think of all the relevgant things to check...
This is a private spreadsheet.
Should be accessible to you now.
Comment ActionsThe responses were also not returning an etag header, as previously expected.
That shouldn't have been the case... you are seeing the etags now, right?
Can you deploy to test.wikipedia.org first this time and give us like a week?
Not sure how easy it is to have gateway rules depend on the wiki domain... @akosiaris ?
Comment ActionsYes, it is doable, although not an exception we 'd like to carry for a prolonged period of time. A week sounds fine though.
Comment Actions@Quiddity has a point here, lack of sufficient communication has backfired once already, it's prudent to over communicate this time around to avoid similar issues.
I think the exact wording, as well as timing, is up to MW-Interfaces-Team, so I 'll refrain from suggesting one, but HCoplin-WMF added a comment.Nov 8 2024, 9:15 PM
Comment ActionsConfirming that we are including a callout for this work in this week's Tech News. Thanks for the nudge @akosiaris and @Quiddity !
Comment ActionsChange #1087568 merged by jenkins-bot:
[mediawiki/core@master] REST: Allow page endpoint "redirect" parameter to have value "false".
Comment ActionsFor the record, this got sent out in https://meta.wikimedia.org/wiki/Tech/News/2024/46
The exact wording was:
Wikimedia REST API users, such as bot operators and tool maintainers, may be affected by ongoing upgrades. The API will be rerouting some page content endpoints from RESTbase to the newer MediaWiki REST API endpoints. The impacted endpoints include getting page/revision metadata and rendered HTML content. These changes will be available on testwiki later this week, with other projects to follow. This change should not affect existing functionality, but active users of the impacted endpoints should verify behavior on testwiki, and raise any concerns on the related Phabricator ticket.
Comment ActionsThe redirect parameter fix is now live on all production wikis.
Given that we want rerouting to only test to be temporary, and given that the US Thanksgiving holiday is next week, could/should we plan to do this the week of Dec 2nd?
What timing works for Service Ops? @Legoktm , is there any particular timing that would be more less convenient for you?
HCoplin-WMF added a comment.Dec 2 2024, 3:05 PMComment ActionsHey there! Please confirm when you've completed the rerouting on the test wiki. I will be sending a corresponding update/call to action on the Wikitech-l distro for folks to start testing once it's officially rerouting.
Related: I met with the RESTbase folks, and we are all aligned on delaying rolling this out to other projects until the new year. We would like to avoid risk related to breaking changes while folks are out for end-of-year holidays. @MSantos and/or I will send out a corresponding timeline update (and follow up testing announcement) via Tech News.
Comment ActionsChange #1100112 had a related patch set uploaded (by Alexandros Kosiaris; author: Alexandros Kosiaris):
[operations/puppet@production] gateway-check: Support per wiki rules
Comment ActionsHCoplin-WMF added a comment.Dec 3 2024, 4:27 PM
Comment ActionsFabulous! Thank you so much for all the support on this, @akosiaris !
Comment ActionsChange #1100112 merged by Alexandros Kosiaris:
[operations/puppet@production] gateway-check: Support (and use) per wiki rules
Comment ActionsChange merged and deployed. Thanks to @Scott_French for their comments which lowered code complexity and helped make it more readable.
So:
curl -v https://test.wikipedia.org/api/rest_v1/page/title/Test45 |& grep -Ei 'server|x-restbase'
< server: envoy
< vary: x-restbase-compat
< server-timing: cache;desc="hit-local", host;desc="cp3070"
whereas
curl -v https://en.wikipedia.org/api/rest_v1/page/title/Earth |& grep server
< server: restbase1037
I 'll be monitoring, but for now everything looks good.
@Legoktm test.wikipedia.org's rest_v1/page/html and rest_v1/page/title endpoints are ready for your tests.
HCoplin-WMF added a comment.Jan 6 2025, 5:00 PMComment ActionsHello! Since we're all back for the new year, let's get this rolling again. @akosiaris -- if your team good to flip the switch the week of Monday, Jan 13? I haven't heard any feedback so far, but would like to give one more reminder through the tech news channels this week.
@Legoktm -- were you also able to test? Are things looking good on your side with the test endpoints?
HCoplin-WMF added a comment.Jan 14 2025, 2:24 PMComment Actions@akosiaris -- just confirming that no issues were raised in response to the final reminder last week.
@Legoktm -- do you have any final concerns? If not, I think we should be good to go :)
Comment ActionsNone from me, I tried the mwbot-rs test suite against test.wikipedia.org and it all seems fine (I didn't see a linked patch for the etag stuff but I assume someone checked/addressed it? I can't reproduce the failure on test.wikipedia.org.). There's still T380015 that doesn't have a clear path forward, but maybe T354037#10397337 is the way forward?
Thanks all for the extra work in setting up test.wikipedia.org and the communications.
Comment ActionsThe page/html endpoint returns an etag. There's no patch because that didn't change - as far as I can tell, it has been returning etags for a long time. What failure were you trying to reproduce?
There's still T380015 that doesn't have a clear path forward, but maybe T354037#10397337 is the way forward?
Yes, using flavor=edit is the preferred solution. It should solve the problem. But you would be the first real world user, so please let use know if there are any issues. (flavor=edit was originally designed for use with VisualEditor, but we ended up doing that directly in PHP instead of going through the API).
Comment ActionsChange #1112188 had a related patch set uploaded (by Alexandros Kosiaris; author: Alexandros Kosiaris):
[operations/puppet@production] Map rest_v1/page/(html|title)/ to rest-gateway
HCoplin-WMF added a comment.Jan 17 2025, 1:09 PM
Comment ActionsI figured, @akosiaris ! Thanks for the confirmation, and I hope you feel better soon.
Thanks for the follow up too, @Legoktm. Glad to hear that everything is looking good on test wiki, and thanks again for both your patience and diligence. This was a good learning experience for us, so hopefully we won't run into similar issues with future updates. I look forward to doing this style of rollout on test wiki for future changes, as well.
Comment ActionsChange #1112188 merged by Alexandros Kosiaris:
[operations/puppet@production] Map rest_v1/page/(html|title)/ to rest-gateway
Comment ActionsYup, I 've switched indeed to Jan 21st. Patch has just been merged and will be making it's way throughout the fleet in the next 30minutes.
I did a test in just esams and output looks OK
{
"items": [
{
"title": "Earth",
"page_id": 9228,
"rev": 1270541959,
"tid": "DUMMY",
"namespace": 0,
"user_id": 44217690,
"user_text": "Panamitsu",
"timestamp": "2025-01-20T01:26:38Z",
"comment": "Undid revision [[Special:Diff/1270541657|1270541657]] by [[Special:Contributions/Einstein3.1415926535!|Einstein3.1415926535!]] ([[User talk:Einstein3.1415926535!|talk]]) There is already a citation for that fact later in the article. This article doesn't have citations in the lead.",
"tags": [
"mw-undo",
"wikieditor"
],
"restrictions": [],
"page_language": "en",
"redirect": false
}
]
}
which compared to old output
{
"items": [
{
"title": "Earth",
"page_id": 9228,
"rev": 1270541959,
"tid": "80cf8cb0-d7db-11ef-a3b1-d92e07b424bc",
"namespace": 0,
"user_id": 44217690,
"user_text": "Panamitsu",
"timestamp": "2025-01-20T01:26:38Z",
"comment": "Undid revision [[Special:Diff/1270541657|1270541657]] by [[Special:Contributions/Einstein3.1415926535!|Einstein3.1415926535!]] ([[User talk:Einstein3.1415926535!|talk]]) There is already a citation for that fact later in the article. This article doesn't have citations in the lead.",
"tags": [
"mw-undo",
"wikieditor"
],
"restrictions": [],
"page_language": "en",
"redirect": false
}
]
}
is identical (minus the tid, which has already been covered in T374683#10292754). Leaving open to monitor for a couple of days and I think we can resolve after that.
Comment Actions$ curl -i 'https://en.wikipedia.org/w/rest.php/v1/page/Wikipedia%3ARequests_for_adminship%2Ftheleekycauldron_2/html?redirect=false'
HTTP/2 200
date: Sat, 25 Jan 2025 22:31:01 GMT
server: mw-api-ext.eqiad.main-b576cd585-v9j2n
x-content-type-options: nosniff
cache-control: no-cache
content-language: en
content-revision-id: 1170967427
access-control-allow-origin: *
last-modified: Fri, 24 Jan 2025 18:49:47 GMT
content-type: text/html; charset=utf-8; profile="https://www.mediawiki.org/wiki/Specs/HTML/2.8.0"
vary: x-restbase-compat, Accept-Encoding
age: 2
x-cache: cp1112 hit, cp1112 miss
x-cache-status: hit-local
server-timing: cache;desc="hit-local", host;desc="cp1112"
strict-transport-security: max-age=106384710; includeSubDomains; preload
report-to: { "group": "wm_nel", "max_age": 604800, "endpoints": [{ "url": "https://intake-logging.wikimedia.org/v1/events?stream=w3c.reportingapi.network_error&schema_uri=/w3c/reportingapi/network_error/1.0.0" }] }
nel: { "report_to": "wm_nel", "max_age": 604800, "failure_fraction": 0.05, "success_fraction": 0.0}
set-cookie: WMF-Last-Access=25-Jan-2025;Path=/;HttpOnly;secure;Expires=Wed, 26 Feb 2025 12:00:00 GMT
set-cookie: WMF-Last-Access-Global=25-Jan-2025;Path=/;Domain=.wikipedia.org;HttpOnly;secure;Expires=Wed, 26 Feb 2025 12:00:00 GMT
x-client-ip: 151.202.4.10
set-cookie: GeoIP=US:NY:Brooklyn:40.73:-73.94:v4; Path=/; secure; Domain=.wikipedia.org
set-cookie: NetworkProbeLimit=0.001;Path=/;Secure;SameSite=Lax;Max-Age=3600
accept-ranges: bytes
This is the same failure I reported in T374683#10294212 and T374683#10296784.
I'm not sure why it only affects some pages though. For example, the Main Page is fine:
$ curl -I 'https://en.wikipedia.org/w/rest.php/v1/page/Main_Page/html?redirect=false' | grep etag
etag: W/"1267837350/700f3eff-db65-11ef-a156-934bb9987377/view/html"
Comment ActionsI found T357603: REST API: ETag missing from some responses from page HTML endpoint which seems to be the cause. In the prior example, when I remove ?redirect=false, an etag shows up:
$ curl -I 'https://en.wikipedia.org/w/rest.php/v1/page/Wikipedia%3ARequests_for_adminship%2Ftheleekycauldron_2/html'| grep etag
etag: W/"1170967427/fbb0a9e1-da83-11ef-9f0b-99a171ff8019/view/html"
Comment ActionsOddly, it doesn't for me. I don't get an ETag there. But if I try other random pages, I do get an etag. It's really strange.
I can't reproduce this issue locally, and I do get etags for *most* pages, with or without query params. I wonder if the issue is with the frontend cache. But I don't really see the pattern:
No etag:
x-cache: cp3071 hit, cp3071 miss
x-cache-status: hit-local
With etag:
x-cache: cp3071 hit, cp3071 pass
x-cache-status: hit-local
With etag:
x-cache: cp3071 miss, cp3071 miss
x-cache-status: miss
With etag:
x-cache: cp3071 miss, cp3071 hit/1
x-cache-status: hit-front
HCoplin-WMF edited projects, added MW-Interfaces-Team (MWI-Sprint-1 (2025-01-14 to 2025-01-28)); removed MW-Interfaces-Team (MWI-Sprint-2 (2025-01-28 to 2025-02-11)).HCoplin-WMF added a comment.Mon, Mar 10, 1:26 PMComment Actions@Legoktm leaving out an incident report was unintentional. I was frankly not aware of that mechanism. We will be more diligent in the case of any future accidental breaking changes.
Additionally, just want to confirm that we will be providing more transparency and a proactive test period for additional rerouting work related to the RESTbase sunset. You should see those announcements coming soon-ish. Would love to get your input and testing support on those iterations!
Comment ActionsReport for what incident? The missing ETags? The handling of the redirect parameter? Both were regrettable bugs, but not substantial operational issues or problems with broad impact on users. As far as I can tell, the redirect=false issue primarily affects your bot, plus a handful of others to a lesser degree, at a total of about 1400 requests a day: Terms of Use · Credits
Subject | Repo | Branch | Lines +/- | |
---|---|---|---|---|
gateway-check: Support (and use) per wiki rules | mediawiki/core | production | +0 -3 | |
Fixup for rest-gateway's request_headers_to_add | operations/puppet | production | +3 -0 | |
rest-gateway: Route page and html RESTBase routes to mw-api-int | Comment Actions Yes, this is fine. The TID value designed as a transparent token. It can be used as a path parameter in future request, but that parameter has already been ignored for several months now. Comment Actions Most of my bots and tools that used RESTBase are now broken, and I suspect this is the cause based on timing. I expect there are probably 20-25 tools that are broken, and a similar number of bots across a number of wikis. Here's the main error I'm seeing so far: HTTP error: HTTP status client error (400 Bad Request) for url (https://en.wikipedia.org/w/rest.php/v1/page/Wikipedia%3AMiscellany_for_deletion%2FArchived_debates%2FNovember_2024/html?redirect=false) Another error is these responses are no longer returning etags, which used to be guaranteed (and necessary!). I haven't had the chance to track down further things yet and honestly it shouldn't be on me do this in an emergency mode, this is ridiculous. There's been literally no communication about this (which I pointed out back in T334238#10107841 in August), and when we've been proactive about asking for help, we've been met entirely with silence: T354037. I don't even know if this is feasible to revert, but the status quo isn't acceptable. Edit: Just to add, bugs and regressions are fine, they happen, and that's unavoidable. The problem is not communicating about what is happening, especially when people are actively making an effort to be involved and literally help you. I want to get off RESTBase and have been trying to do that for months now and am stuck because people aren't communicating. Comment Actions Change #1087568 had a related patch set uploaded (by BPirkle; author: BPirkle): [mediawiki/core@master] REST: Allow page endpoint "redirect" parameter to have value "false". HCoplin-WMF added a comment.Nov 5 2024, 10:36 PM @Legoktm -- this was 100% an unintended breakage that we are working to resolve as we speak. This change was supposed to be a clean reroute, with 0 impact to all API users. We will be rolling back the change imminently, while we create an updated PR to resolve the issue at its root. Sincere apologies for the accidental break, and we will get it resolved as soon as possible. Wholeheartedly agree that this should not be an emergency drill for you, as there should be no changes required on your side. I also want to recognize and apologize for the slight delay in response and action since you flagged. It is election day in the US, so our engineers who are normally responding this time of day are out voting! Comment Actions Change #1087591 had a related patch set uploaded (by Arlolra; author: Arlolra): [operations/puppet@production] Revert "Revert^2 "ats: Route rest_v1/page/(html|title) to rest-gateway"" Comment Actions Change #1087591 merged by Ladsgroup: [operations/puppet@production] Revert "Revert^2 "ats: Route rest_v1/page/(html|title) to rest-gateway"" Comment Actions Sounds good. I'll give the revert ~20 more minutes to roll out fully and report back to see if things are fixed.
This is a reasonable goal, but I don't think it justfies the lack of communication. Shit happens, just let us know what to expect ahead of time. For example, if this was deployed to test.wikipedia.org first, our automated test suite would've run against it and caught it. Redirecting a big chunk of RESTBase over to rest.php is genuinely a big deal (as evidenced by how long it took to get here!!) and should be something people are shouting from the rooftops in celebration, not complaining about.
Makes sense, hopefully we can dig into this properly in the incident report (e.g. should U.S. election day be a no deploy day given low availability). Comment Actions Before rolling out the switch again, it might be a good idea to survey all query parameters that are accepted for compatibility, if that hasn't been done already. Moreover: do we have a set of urls that we've tested to work? It might be useful for us so that we can prepare an httpbb test suite to run before and after switching one host for validating the change. Comment Actions Yes, I just double-checked - the only other supported query parameter is stash, which can be true or false.
That would be nice, but it wouldn't have caught the problem we just encoutnered either - I wouldn't have thought to check for redirect=false. Known good cases are easy to cover, unknown bad cases are easy to miss... Also, we may encounter problems that are more subtle - etag handling or cache control headers or CORS or whatnot. I checked all the stuff that I could think of a while ago, see Comment Actions That all makes sense, but also now seems like the perfect time to encode a bunch of this lost-then-rediscovered knowledge into httpbb rules. This is a Comment Actions The responses were also not returning an etag header, as previously expected. AFAIK redirect=false was always the canonical way to pass it (c.f. T130757#2184827). And like I said, this is all in the mwbot-rs test suite. Can you deploy to test.wikipedia.org first this time and give us like a week?
This is a private spreadsheet. Comment Actions It seems like this should be included in the next (or a near-future) Tech News edition. https://docs.google.com/spreadsheets/d/10FaxUcD6y4Xjss21HfXUwVsH98RCWO7Bs9hhZuDTfFg/edit?pli=1&gid=0#gid=0. But as we just found out, I didn't think of all the relevgant things to check...
This is a private spreadsheet. Should be accessible to you now. Comment Actions
That shouldn't have been the case... you are seeing the etags now, right?
Not sure how easy it is to have gateway rules depend on the wiki domain... @akosiaris ? Comment Actions Yes, it is doable, although not an exception we 'd like to carry for a prolonged period of time. A week sounds fine though. Comment Actions @Quiddity has a point here, lack of sufficient communication has backfired once already, it's prudent to over communicate this time around to avoid similar issues. I think the exact wording, as well as timing, is up to MW-Interfaces-Team, so I 'll refrain from suggesting one, but HCoplin-WMF added a comment.Nov 8 2024, 9:15 PM Confirming that we are including a callout for this work in this week's Tech News. Thanks for the nudge @akosiaris and @Quiddity ! Comment Actions Change #1087568 merged by jenkins-bot: [mediawiki/core@master] REST: Allow page endpoint "redirect" parameter to have value "false". Comment Actions For the record, this got sent out in https://meta.wikimedia.org/wiki/Tech/News/2024/46 The exact wording was:
Comment Actions The redirect parameter fix is now live on all production wikis. Given that we want rerouting to only test to be temporary, and given that the US Thanksgiving holiday is next week, could/should we plan to do this the week of Dec 2nd? What timing works for Service Ops? @Legoktm , is there any particular timing that would be more less convenient for you? HCoplin-WMF added a comment.Dec 2 2024, 3:05 PM Comment ActionsHey there! Please confirm when you've completed the rerouting on the test wiki. I will be sending a corresponding update/call to action on the Wikitech-l distro for folks to start testing once it's officially rerouting. Related: I met with the RESTbase folks, and we are all aligned on delaying rolling this out to other projects until the new year. We would like to avoid risk related to breaking changes while folks are out for end-of-year holidays. @MSantos and/or I will send out a corresponding timeline update (and follow up testing announcement) via Tech News. Comment Actions Change #1100112 had a related patch set uploaded (by Alexandros Kosiaris; author: Alexandros Kosiaris): [operations/puppet@production] gateway-check: Support per wiki rules Comment Actions HCoplin-WMF added a comment.Dec 3 2024, 4:27 PM Fabulous! Thank you so much for all the support on this, @akosiaris ! Comment Actions Change #1100112 merged by Alexandros Kosiaris: [operations/puppet@production] gateway-check: Support (and use) per wiki rules Comment Actions Change merged and deployed. Thanks to @Scott_French for their comments which lowered code complexity and helped make it more readable. So: curl -v https://test.wikipedia.org/api/rest_v1/page/title/Test45 |& grep -Ei 'server|x-restbase' < server: envoy < vary: x-restbase-compat < server-timing: cache;desc="hit-local", host;desc="cp3070" whereas curl -v https://en.wikipedia.org/api/rest_v1/page/title/Earth |& grep server < server: restbase1037 I 'll be monitoring, but for now everything looks good. @Legoktm test.wikipedia.org's rest_v1/page/html and rest_v1/page/title endpoints are ready for your tests. HCoplin-WMF added a comment.Jan 6 2025, 5:00 PM Comment ActionsHello! Since we're all back for the new year, let's get this rolling again. @akosiaris -- if your team good to flip the switch the week of Monday, Jan 13? I haven't heard any feedback so far, but would like to give one more reminder through the tech news channels this week. @Legoktm -- were you also able to test? Are things looking good on your side with the test endpoints? HCoplin-WMF added a comment.Jan 14 2025, 2:24 PM Comment Actions@akosiaris -- just confirming that no issues were raised in response to the final reminder last week. @Legoktm -- do you have any final concerns? If not, I think we should be good to go :) Comment Actions None from me, I tried the mwbot-rs test suite against test.wikipedia.org and it all seems fine (I didn't see a linked patch for the etag stuff but I assume someone checked/addressed it? I can't reproduce the failure on test.wikipedia.org.). There's still T380015 that doesn't have a clear path forward, but maybe T354037#10397337 is the way forward? Thanks all for the extra work in setting up test.wikipedia.org and the communications. Comment Actions The page/html endpoint returns an etag. There's no patch because that didn't change - as far as I can tell, it has been returning etags for a long time. What failure were you trying to reproduce?
Yes, using flavor=edit is the preferred solution. It should solve the problem. But you would be the first real world user, so please let use know if there are any issues. (flavor=edit was originally designed for use with VisualEditor, but we ended up doing that directly in PHP instead of going through the API). Comment Actions Change #1112188 had a related patch set uploaded (by Alexandros Kosiaris; author: Alexandros Kosiaris): [operations/puppet@production] Map rest_v1/page/(html|title)/ to rest-gateway HCoplin-WMF added a comment.Jan 17 2025, 1:09 PM I figured, @akosiaris ! Thanks for the confirmation, and I hope you feel better soon. Thanks for the follow up too, @Legoktm. Glad to hear that everything is looking good on test wiki, and thanks again for both your patience and diligence. This was a good learning experience for us, so hopefully we won't run into similar issues with future updates. I look forward to doing this style of rollout on test wiki for future changes, as well. Comment Actions Change #1112188 merged by Alexandros Kosiaris: [operations/puppet@production] Map rest_v1/page/(html|title)/ to rest-gateway Comment Actions Yup, I 've switched indeed to Jan 21st. Patch has just been merged and will be making it's way throughout the fleet in the next 30minutes. I did a test in just esams and output looks OK { "items": [ { "title": "Earth", "page_id": 9228, "rev": 1270541959, "tid": "DUMMY", "namespace": 0, "user_id": 44217690, "user_text": "Panamitsu", "timestamp": "2025-01-20T01:26:38Z", "comment": "Undid revision [[Special:Diff/1270541657|1270541657]] by [[Special:Contributions/Einstein3.1415926535!|Einstein3.1415926535!]] ([[User talk:Einstein3.1415926535!|talk]]) There is already a citation for that fact later in the article. This article doesn't have citations in the lead.", "tags": [ "mw-undo", "wikieditor" ], "restrictions": [], "page_language": "en", "redirect": false } ] } which compared to old output { "items": [ { "title": "Earth", "page_id": 9228, "rev": 1270541959, "tid": "80cf8cb0-d7db-11ef-a3b1-d92e07b424bc", "namespace": 0, "user_id": 44217690, "user_text": "Panamitsu", "timestamp": "2025-01-20T01:26:38Z", "comment": "Undid revision [[Special:Diff/1270541657|1270541657]] by [[Special:Contributions/Einstein3.1415926535!|Einstein3.1415926535!]] ([[User talk:Einstein3.1415926535!|talk]]) There is already a citation for that fact later in the article. This article doesn't have citations in the lead.", "tags": [ "mw-undo", "wikieditor" ], "restrictions": [], "page_language": "en", "redirect": false } ] } is identical (minus the tid, which has already been covered in T374683#10292754). Leaving open to monitor for a couple of days and I think we can resolve after that. Comment Actions $ curl -i 'https://en.wikipedia.org/w/rest.php/v1/page/Wikipedia%3ARequests_for_adminship%2Ftheleekycauldron_2/html?redirect=false' HTTP/2 200 date: Sat, 25 Jan 2025 22:31:01 GMT server: mw-api-ext.eqiad.main-b576cd585-v9j2n x-content-type-options: nosniff cache-control: no-cache content-language: en content-revision-id: 1170967427 access-control-allow-origin: * last-modified: Fri, 24 Jan 2025 18:49:47 GMT content-type: text/html; charset=utf-8; profile="https://www.mediawiki.org/wiki/Specs/HTML/2.8.0" vary: x-restbase-compat, Accept-Encoding age: 2 x-cache: cp1112 hit, cp1112 miss x-cache-status: hit-local server-timing: cache;desc="hit-local", host;desc="cp1112" strict-transport-security: max-age=106384710; includeSubDomains; preload report-to: { "group": "wm_nel", "max_age": 604800, "endpoints": [{ "url": "https://intake-logging.wikimedia.org/v1/events?stream=w3c.reportingapi.network_error&schema_uri=/w3c/reportingapi/network_error/1.0.0" }] } nel: { "report_to": "wm_nel", "max_age": 604800, "failure_fraction": 0.05, "success_fraction": 0.0} set-cookie: WMF-Last-Access=25-Jan-2025;Path=/;HttpOnly;secure;Expires=Wed, 26 Feb 2025 12:00:00 GMT set-cookie: WMF-Last-Access-Global=25-Jan-2025;Path=/;Domain=.wikipedia.org;HttpOnly;secure;Expires=Wed, 26 Feb 2025 12:00:00 GMT x-client-ip: 151.202.4.10 set-cookie: GeoIP=US:NY:Brooklyn:40.73:-73.94:v4; Path=/; secure; Domain=.wikipedia.org set-cookie: NetworkProbeLimit=0.001;Path=/;Secure;SameSite=Lax;Max-Age=3600 accept-ranges: bytes This is the same failure I reported in T374683#10294212 and T374683#10296784. I'm not sure why it only affects some pages though. For example, the Main Page is fine: $ curl -I 'https://en.wikipedia.org/w/rest.php/v1/page/Main_Page/html?redirect=false' | grep etag etag: W/"1267837350/700f3eff-db65-11ef-a156-934bb9987377/view/html" Comment Actions I found T357603: REST API: ETag missing from some responses from page HTML endpoint which seems to be the cause. In the prior example, when I remove ?redirect=false, an etag shows up: $ curl -I 'https://en.wikipedia.org/w/rest.php/v1/page/Wikipedia%3ARequests_for_adminship%2Ftheleekycauldron_2/html'| grep etag etag: W/"1170967427/fbb0a9e1-da83-11ef-9f0b-99a171ff8019/view/html" Comment Actions Oddly, it doesn't for me. I don't get an ETag there. But if I try other random pages, I do get an etag. It's really strange. I can't reproduce this issue locally, and I do get etags for *most* pages, with or without query params. I wonder if the issue is with the frontend cache. But I don't really see the pattern: No etag: With etag: With etag: With etag: HCoplin-WMF edited projects, added MW-Interfaces-Team (MWI-Sprint-1 (2025-01-14 to 2025-01-28)); removed MW-Interfaces-Team (MWI-Sprint-2 (2025-01-28 to 2025-02-11)). HCoplin-WMF added a comment.Mon, Mar 10, 1:26 PM Comment Actions@Legoktm leaving out an incident report was unintentional. I was frankly not aware of that mechanism. We will be more diligent in the case of any future accidental breaking changes. Additionally, just want to confirm that we will be providing more transparency and a proactive test period for additional rerouting work related to the RESTbase sunset. You should see those announcements coming soon-ish. Would love to get your input and testing support on those iterations! Comment Actions Report for what incident? The missing ETags? The handling of the redirect parameter? Both were regrettable bugs, but not substantial operational issues or problems with broad impact on users. As far as I can tell, the redirect=false issue primarily affects your bot, plus a handful of others to a lesser degree, at a total of about 1400 requests a day: Terms of Use · Credits |