Investigating a prolonged flicker of MercIntegration- prices set up in the test fixture were not being passed through, or coming through wrong. It only failed later in the day, though.
Setting up the prices seemed to be working fine: the local database had them after the job ran in CI.
As it turned out, we were setting them up in the right database, but the Merc application under test was reading from the wrong database.
Our local configuration file had:
read_write.mongo.database=market_data_test_tim_integration
Instead it needed:
read_write.mongodb.database=market_data_test_tim_integration
The Merc application has hardcoded defaults - if the database name isn't configured, it defaults to the correct value for production use.
When the property names were changed, the change was typo'd in TIM's configuration, but the incoprrect properties were ignored (which is normal) and the defaults used.
It's tempting to make the "real" configuration work by default, but is it really safe?
Requiring config properties to be set can create extra work as they are added, but does trigger examination of where they are used. (e.g. deployment contract testing requires a minimal config)
Applications could default to a non-production mode, but with e.g. red status components to ensure they don't end up like that in production. (e.g. TIM's stubbed-out Merc and Abacus modes, which are fine for the majority of local TIM development; Investor's empty-read-model mode)