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
In all these cases the property is unconditionally set in
the constructor. The extra initialisation is effectively
dead code and an extra source of errors and confusion.
Change-Id: Icae13390d5ca5c14e2754f3be4eb956dd7f54ac4
This ensures consistent behavior when an ID for a name is first acquired
within a transaction that is rolled back. The documentation for acquireId
now reads:
@note If called within a transaction, there is a chance for the acquired ID to be lost
if the transaction is rolled back. A best effort is made to re-insert the mapping
after a rollback, and consistency of the cache with the database table is ensured
by re-loading the map after a failed transaction. However, there is no guarantee
that an ID returned by this method is valid outside the transaction in which it
was produced. This means that calling code should not retain the return value beyond
the scope of a transaction, but rather call acquireId() again after the transaction
is complete. In some rare cases, this may produce an ID different from the first call.
Bug: T224949
Change-Id: I6d05e4112a649675bfb9083cab2d1bbe394e65b3
This method handles reuseConnection() calls, disallows writes to
DB_REPLICA role handles, is more consistent with wfGetDB(), and
is more efficient with I540b08920997c5.
Change-Id: I8edaef0ea4718414e2004fad04afca8ec5797669
These fields are passed to methods like LoadBalancer::getConnection() and are
already expected to be DB domains. Update various comments as well.
Fix a few minor IDEA warnings.
Change-Id: If480cc4d7d4a3c2d176ab346e6307e80cd2540c5
Rather than have the behavior vary and possibly break code or tests
when small changes happen, make User/NameTableStore more explicit
about when cache key purges happens.
This should reduce problems with certain fragile tests, such as those
that could be affected by 0390811263 when --use-normal tables is not
used. Ideally, any fragility should be ironed out of effected code.
Change-Id: Ibe5d1bb4bece2526bc0da99648f7ba73bdc0ffa5
Resetting the content_model and slot_role tables between test runs
requires the corresponding NameTabelStore instances to be reset
as well. We may however have many of them, buried in various services.
There is no easy way to reset them consistently.
Letting information in these tables persist between tests seems
harmless. Tests that need these tables reset can simply add them
to the tablesUsed array.
This is needed for unit tests to work with the new MCR schema.
Bug: T198561
Change-Id: I63e61e1ab74e00c20930a83d3a3f5df53092a197
This makes explicit the fact that some classes can use the local wiki's default
WANObjectCache instance while still sharing cache entries between wikis.
Bug: T198704
Change-Id: Ic29f79e4b4bd6bdaa844049962a163e72a59c45a
DEPLOYMENT: This changes the cache key for revision
content blobs. Expect a brief rise in ExternalStore hits.
Bug: T198704
Change-Id: Icc2d16bc5a1e27ba4caea49a784ba7aeac15042a
The "AUTO" means AUTOCOMMIT, not "automatic transactions"/DBO_TRX,
which is basically the opposite concept. The new name does not
suffer from that ambiguity.
Keep the old constant as an alias for backwards compatibility.
Also remove LoadBalancer comment about non-existing field
Change-Id: I63beeb061fc9be73f320308e4d6393b58628b8c8