Page MenuHomePhabricator

After a fulltext write to a particular service fails, keep trying writes to other services
ClosedPublic

Authored by epriestley on Apr 2 2017, 4:59 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Oct 26, 2:42 PM
Unknown Object (File)
Thu, Oct 24, 3:03 PM
Unknown Object (File)
Oct 22 2024, 11:30 AM
Unknown Object (File)
Oct 16 2024, 4:58 AM
Unknown Object (File)
Oct 13 2024, 1:20 AM
Unknown Object (File)
Oct 3 2024, 4:54 AM
Unknown Object (File)
Oct 3 2024, 4:52 AM
Unknown Object (File)
Oct 3 2024, 4:51 AM
Subscribers
None

Details

Summary

Ref T12450. Currently, if a write fails, we stop and don't try to write to other index services. There's no technical reason not to keep trying writes, it makes some testing easier, and it would improve behavior in a scenario where engines are configured as "primary" and "backup" and the primary service is having some issues.

Also, make "no writable services are configured" acceptable, rather than an error. This state is probably goofy but if we want to detect it I think it should probably be a config-validation issue, not a write-time check. I also think it's not totally unreasonable to want to just turn off all writes for a while (maybe to reduce load while you're doing a background update).

Test Plan
  • Configured a bad ElasticSearch engine and a good MySQL engine.
  • Ran bin/search index ... --force.
  • Saw MySQL get updated even though ElasticSearch failed.

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

epriestley retitled this revision from After a fulltext write fails, keep trying writes to After a fulltext write to a particular service fails, keep trying writes to other services.Apr 2 2017, 5:05 PM

Yes this seems reasonable.

This revision is now accepted and ready to land.Apr 2 2017, 8:39 PM
This revision was automatically updated to reflect the committed changes.