* Some functions accept only string, cast ints and floats to string
* After preg_matches or explode() casts numbers to int to do maths
* Cast unix timestamps to int to do maths
* Cast return values from timestamp format function to int
* Cast bitwise operator to bool when needed as bool
* php internal functions like floor/round/ceil documented to return
float, most cases the result is used as int, added casts
Found by phan strict checks
Change-Id: Icb2de32107f43817acc45fe296fb77acf65c1786
The functions returning null or the class property is set explict null
Found by phan strict checks
Change-Id: I4a271093fb6526564d8083a08249c64cb21f2453
Connection loss with a failure to reconnect led to a variety of failure
modes, such as an assertion from getBindingHandle() when addQuotes() is
next called. And Maintenance::shutdown() was calling
commitPrimaryChanges() three times, each call leading to an assertion
due to the round stage being broken.
So, try to exit promptly if a DBConnectionError is caught, by
introducing a new "reached" category for fatal exceptions. Guard the
calls to commitPrimaryChanges(), and skip the call prior to shutdown()
since shutdown() calls it already.
Change-Id: I81ee9017a58adac674a9495802f6bd4bcc22ee61
Change the metric names such that they do not overlap between
logically unrelated categories.
One non-overlapping metric for outcomes.
One misc metric for warnings and other unusual observations which
may overlap with outcomes.
Within outcomes, don't require metric queries to the names and/or
manually group them as positive or negative. Use a prefix to
distinguish between early exists that are bad (logged as failure and
will retry), and those that are considered good (no problem,
job superseded, no retry needed).
Bug: T301432
Change-Id: I2d5f3cc7cc2229cd910f341cf1f51d1e26be6e58
If a RefreshLinksJob is created with an improper/invalid title,
executing the job later will fail with a PageAssertionException
while trying to create a WikiPage for that title. Better check
the title when constructing the job, so the offending code is on the
stack when it happens.
Bug: T293291
Depends-On: I7dcfac0eacdd5b22bdf443e88f8e6ddb883b92cc
Change-Id: I77a622591836873415f097453da01ca7e61c41be
Don't catch and discard exceptions from the RequestTimeout library,
except when the exception is properly handled and the code seems to be
trying to wrap things up.
In most cases the exception is rethrown. Ideally it should instead be
done by narrowing the catch, and this was feasible in a few cases. But
sometimes the exception being caught is an instance of the base class
(notably DateTime::__construct()). Often Exception is the root of the
hierarchy of exceptions being thrown and so is the obvious catch-all.
Notes on specific callers:
* In the case of ResourceLoader::respond(), exceptions were caught for API
correctness, but processing continued. I added an outer try block for
timeout handling so that termination would be more prompt.
* In LCStoreCDB the Exception being caught was Cdb\Exception not
\Exception. I added an alias to avoid confusion.
* In ImageGallery I added a special exception class.
* In Message::__toString() the rationale for catching disappears
in PHP 7.4.0+, so I added a PHP version check.
* In PoolCounterRedis, let the shutdown function do its thing, but
rethrow the exception for logging.
Change-Id: I4c3770b9efc76a1ce42ed9f59329c36de04d657c
When the called function has a doc of int, it should be cast to be
explicit here.
Also cast for arithmetic operations to be explicit about the number
Change-Id: I905b78dfb66e66443e0e3203488bab5b548db543
Currently this is implemented internally as a second method call. In the
future, it might be possible to optimize the implementation, e.g. to
reduce the amount of DB queries/jobs etc. without changing anything for
callers.
Since the implementation of e.g. the result getters is generic, a future
commit may add an option to delete subpages with relatively low effort.
The revision limit for big deletions is now using the total number of
revisions (base page + talk page). This is because both deletions would
happen in the same main transaction, and we presumably want to optimize
the deletion as a whole, not as two separated steps. This would become
even more important if the aforementioned improvements are ever
implemented. Note, the whole concept of "big deletion" might have been
superseded by batched deletions in the author's opinion, but as long as
such a limit exists, it should serve its purpose.
The current interpretation of the associated talk option is that the
request is validated, and an exception is raised if we cannot delete the
associated talk, as opposed to silently ignoring the parameter if the
talk cannot be deleted. The only exception to this is that it will not
fail hard if the talk page turns out not to exist by the time the
deletion is attempted, as that's hard to foresee due to race conditions.
Note that the summary for the talk deletion is prefixed with the
delete-talk-summary-prefix message. The main reason behind this is that
the delete UI can sometimes offer an auto-generated summary like "the
only contributor was XXX" or "the content was YYY", and since this may
not apply to the talk page as well, the log entry might look confusing.
Bug: T263209
Bug: T27471
Change-Id: Ife1f4e8258a69528dd1ce8fef8ae809761aa6f1d
Might cause issues with queued jobs, possibly something else, as per
comments at I32679b7cacc638ec3e9dc5b8dfe9bcc794b22ecf.
Change-Id: I851aeb9af068d31a48f8f6a3ba98751374e88b6e
In retrospect, I rushed the previous patch: we really need a way to tell
which deletion an ID belong to (and whether it was scheduled). So make
both result getters return an array with known keys that can be used
programmatically. Right now the class can only delete a single page, and
thus there's a single constant and this change is effectively a noop.
The deletionWasScheduled() method, introduced in 1.37, was
hard-deprecated out of an abundance of caution. There are no known uses
on codesearch, so it can probably just be removed in the next release.
Also reorder constructor params to DeletePage -- BacklinkCacheFactory is
a service injected by the factory, hence it shouldn't be grouped
together with value objects injected by the caller.
Change-Id: I32679b7cacc638ec3e9dc5b8dfe9bcc794b22ecf
Introduce a constant to track the maximum number of double redirects
jobs in the job queue. Before we allow 10000 to spread in the code
base, we can just change the constant now and references of this value
will be changed.
Does this qualify to be a configuration or a regular constant will do?
Change-Id: I10c45a8c1cd5b3382edebf9a05f4b3f94f5327df
JobQueueGroup::get( $type ) returns a new object for each job type even
if it's the same class (default class). Also it builds different queues
and push them separelty a couple lines lower limiting the ability to
batch push them in the default job queue object.
Given that JobQueue cares about job types being the same as the class
type (which is important for JobQueueDB implementation), adding a config
option called typeAgnostic to ignore type mismatch in JobQueue
implementations that don't care about the type (like JobQueueEventBus)
Bug: T292048
Change-Id: I151f067ca94a985c816446b545921c387b083911
For both LinkTarget and PageReference, just extract
namespace and dbkey and pass those in the array
of parameters to Job::__construct().
Allows a bunch of simplification to WatchedItemStore.
Bug: T291531
Change-Id: Id150d0c62af38d4b3d17e5698866127c6e04717e
With this patch deprecation warnings will be emitted
if $wgUser is accessed or written into. The only pattern
of usage still allowed is
$oldUser = $wgUser;
$wgUser = $newUser;
// Do something
$wgUser = $oldUser;
Once there is no deprecation warnings, we know that nothing
legitimately depends on $wgUser being set, so we can safely
remove the code that's still allowed as well.
Bug: T267861
Change-Id: Ia1c42b3a32acd0e2bb9b0e93f1dc3c82640dcb22
Queries that query a value "1" are expected to return either
that "1" (possibly as a string), or false. It's safe to simply
cast this to bool and use it as it is.
Queries for COUNT(*) are expected to return that number,
possibly as a string. It's not possible for such a query to
return false. And even if, casting to 0 is fine.
I found an existing code style where the table name and the
"1" are on the same line as the selectField() method name, and
applied it to all similar queries.
Change-Id: I9453196281871c03ef03f653f43762eb9284342f
