Change Details

Problem: A client performs a write action via the API, and wants to perform a subsequent action that requires the first write to have been completed. E.g. 1) create account 2) add groups 3) log in. In this example, the problem is aggravated by the fact that adding user groups requires elevated privileges, so it would have to be done with a logged in client session distinct from the one that does step (3). Solution: Add support for a waitforreplication flag ApiMain. If this flag is set, LBFactory::waitForReplication() is called before the response is sent to the client (unless an error occurred, in which case no wait happens). The response should indicate whether the wait actually happened or not. To avoid abuse, this behavior can be restricted to POST requests, perhaps only those that also require a token. We could be even more restrictive and require a special permission for this, which can then be restricted to a trusted groups, like the bot and sysop groups. Background: The #core_platform_team is working on a suite of API tests. These tests will need to test use cases that span multiple users, with minimal delay between requests, potentially in an environment with replicated databases like the beta cluster. Examples of such use cases to be tested are a user getting a newtalk notification when another user edits their talk page, or a user seeing an edit by another user in their watchlist.

Problem: A client performs a write action via the API, and wants to perform a subsequent action that requires the first write to have been completed. E.g. 1) create account 2) add groups 3) log in. In this example, the problem is aggravated by the fact that adding user groups requires elevated privileges, so it would have to be done with a logged in client session distinct from the one that does step (3). == Solution 1 (as originally proposed, for context) == Add support for a waitforreplication flag ApiMain. If this flag is set, LBFactory::waitForReplication() is called before the response is sent to the client (unless an error occurred, in which case no wait happens). The response should indicate whether the wait actually happened or not. To avoid abuse, this behavior can be restricted to POST requests, perhaps only those that also require a token. We could be even more restrictive and require a special permission for this, which can then be restricted to a trusted groups, like the bot and sysop groups. == Solution 2 == Instead of a flag for the API, introduce a header field that could be used to make any request to MediaWiki wait until its effects have propagated to all replicas. == Solution 3 == Use ChronologyProtector to ensure consistency between the requests. No modification of MediaWiki is necessary. == Background: == The #core_platform_team is working on a suite of API tests. These tests will need to test use cases that span multiple users, with minimal delay between requests, potentially in an environment with replicated databases like the beta cluster. Examples of such use cases to be tested are a user getting a newtalk notification when another user edits their talk page, or a user seeing an edit by another user in their watchlist.

Problem: A client performs a write action via the API, and wants to perform a subsequent action that requires the first write to have been completed. E.g. 1) create account 2) add groups 3) log in. In this example, the problem is aggravated by the fact that adding user groups requires elevated privileges, so it would have to be done with a logged in client session distinct from the one that does step (3). == Solution:ion 1 (as originally proposed, for context) == Add support for a waitforreplication flag ApiMain. If this flag is set, LBFactory::waitForReplication() is called before the response is sent to the client (unless an error occurred, in which case no wait happens). The response should indicate whether the wait actually happened or not. To avoid abuse, this behavior can be restricted to POST requests, perhaps only those that also require a token. We could be even more restrictive and require a special permission for this, which can then be restricted to a trusted groups, like the bot and sysop groups. Background:== Solution 2 == Instead of a flag for the API, introduce a header field that could be used to make any request to MediaWiki wait until its effects have propagated to all replicas. == Solution 3 == Use ChronologyProtector to ensure consistency between the requests. No modification of MediaWiki is necessary. == Background: == The #core_platform_team is working on a suite of API tests. These tests will need to test use cases that span multiple users, with minimal delay between requests, potentially in an environment with replicated databases like the beta cluster. Examples of such use cases to be tested are a user getting a newtalk notification when another user edits their talk page, or a user seeing an edit by another user in their watchlist.