Validate strategy for waiting for Page Content Service content to be updated
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	JoeWalsh
	May 7 2020, 6:20 PM

Description

After a user edits content, the apps would like to show the updated content from the page content service. If the request is made immediately after the edit, the content is still out of date.

The current proposed strategy to wait for the updated content is to make periodic HEAD requests with the If-None-Match header set to the ETag of the content we have until we get a response code of 200 indicating that the ETag has changed. We could take this one step further and compare the revision number returned by the edit to ensure we have the correct revision.

This polling would only happen after the user makes an edit and would stop after 5 attempts. Currently the requests are spaced out with an exponential backoff, with 0.25 * 2 ^ attemptIndex seconds in between each attempt, attemptIndex ranges from 0-4.

Is this an acceptable approach? Are there other alternatives?

Event Timeline

JoeWalsh created this task.May 7 2020, 6:20 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMay 7 2020, 6:20 PM

daniel moved this task from Inbox to Triage Meeting Inbox on the Platform Engineering board.May 8 2020, 9:48 AM

JoeWalsh updated the task description. (Show Details)May 8 2020, 5:18 PM

JoeWalsh updated the task description. (Show Details)

You're talking about mobile-html endpoint right? It supports providing a revision ID to require a new revision. On normal views it's better to use URI without a revision ID, so that you have better cache hit ratio, but after en edit supplying revision ID in the request will have a lot of benefits:

It will bypass Varnish - you are guaranteed to get the new revision, and you're mostly guaranteed to not get a cache hit. This will completely eliminate confusing bugs of not being your own edit right after saving an edit.
It will force RESTBase to generate the correct revision of the page.

Basically, by supplying the new revision ID you will bypass all caching if the new render is not ready yet. Most likely the request will take longer - the content will need to be generated, but since you already are waiting, that doesn't matter. Additional load due to this would be negligible. VE already does it this way. I thought we've added revision parameter for mobile-sections just for this purpose as well.

@Pchelolo Thanks for the response, that sounds good. For the case that the user edits the Wikidata description for the article and we don't have a new article revision will it work to request the existing article revision or is the polling method required?

In T252146#6119587, @JoeWalsh wrote:

@Pchelolo Thanks for the response, that sounds good. For the case that the user edits the Wikidata description for the article and we don't have a new article revision will it work to request the existing article revision or is the polling method required?

Hm... For transclusions (when you don't really edit the article itself) you'd need to force bypassing the cache in some different way. We really don't want to allow force caches bypassing in general cause it would open huge surface for DDOS attack. Maybe once we have a nifty rate limiter that's being developed now to only allow forced cache bypassing with a relatively low rate, we'd allow that. But for now it case of transcluded articles I guess your polling idea is the only way.

I'm not sure what else to do here.

All set here. Thanks!

Validate strategy for waiting for Page Content Service content to be updatedClosed, ResolvedPublicActions

Description

Event Timeline

Validate strategy for waiting for Page Content Service content to be updated
Closed, ResolvedPublic
Actions