Hide truncatedresult warnings #2
Comments
|
Fun fact: |
|
Keep in mind, though, that currently this package nominally supports m3api all the way down to 0.1, which didn’t have warning support yet. So code defensively, or perhaps raise the peer dependency version. |
|
Also, I’d say that not all the request-making methods should hide this warning. In particular, the “partial” methods don’t handle truncated responses (and don’t include the continuation in the return value, so the caller can’t really handle truncated responses correctly either), so I’d say those should continue to show the warning. |
If lucaswerkmeister/m3api#14 is implemented, we’d presumably want to use that in this package, so in that case we’d raise the peer dependency version anyways. (And I think as long as m3api hasn’t reached 1.0 yet, it’s acceptable for m3api-query to only support recent-ish m3api versions.) |
Since we’re fully in control of the execution flow within a batch (from which the user can only escape by throwing in the reducer), we know that we’ll also retrieve the rest of the truncated result, and the warning about incomplete data would only apply if the reducer was programmed to drop the data from the following responses, despite this function being the one you use when you don’t want that problem. In other words, this function is the solution to the truncated responses problem (among others), so we should hide the truncated responses warning. We can reliably recognize the warning even in errorformat=bc (I think), because in that case the message is always in English, and does not use local (on-wiki) messages either: it’s effectively a string hard-coded into MediaWiki. And within MediaWiki, the message has been very stable: it accidentally gained an extra space between MediaWiki 1.26 and 1.28, but otherwise it’s remained constant. So in cases where the warning doesn’t have a code, we can check the message instead. Finishes #14; see also lucaswerkmeister/m3api-query#2.
This lets m3api do some of our work for us; it requires the latest m3api release, but I think it’s acceptable to require recent versions while m3api is still pre-1.0. Part of #2, but we should do the same for queryFullPageByTitle(), at least. Conceptually, queryIncrementalPageByTitle() should also hide truncatedresult warnings, but I don’t see how to implement that function using requestAndContinueReducingBatch()… maybe we can just drop that, possibly along with queryPartialPageByTitle()?
Part of the purpose of this module is to automatically handle truncated responses, so we should hide this warning if it happens.
The text was updated successfully, but these errors were encountered: