This bug been identified as part of Chrome's flake reduction initiative. Resolution of this issue is critical because it has a large impact on the stability of Chrome CI/CQ. Resolving these issues will be essential to meet Chrome’s flake reduction goals.

This bug has led to a large number of gardened builds failing in the last 7 days. List of gardened build failures caused by this cluster can be viewed at:
https://data.corp.google.com/sites/chrome_generic_flakiness_dashboard_datasite/build_failures/?av=rpqxzw:ktu56&fb=is_sheriff_or_cq_builder:eq:true&f=cluster_name:in:b%2F400617105
or in LUCI Analysis and grouped by builders:
https://luci-milo.appspot.com/ui/tests/p/chromium/rules/3519deb73451d0c9b91241ccea2406fa?tab=recent-failures&filterToMetric=builds-failed-due-to-flaky-tests&groupBy=builder&orderBy=invocationFailures

Please consider the following strategies to mitigate the impact from this issue which are rated in order of resolution preference:
1. Resolve the underlying test issue.
2. Move the flaky test from Critical Builders to FYI Builder
3. Disable test (least desirable as it reduces test coverage) and add a Test-Disabled label to this issue. The disabled tests might continue running in reviver builders (go/test-reviver), see config [1] for a list of supported builders.

http://go/resolve-chrome-top-flakes provides more information on the tools available for resolving flaky tests.

When investigating this failure, you may identify this bug is too broad (encompasses multiple different issues) or too narrow (only captures one part of a larger issue). If this applies, you can combine issues[2]  or split issues[3].

Links:
[1] https://source.chromium.org/chromium/chromium/src/+/main:infra/config/subprojects/reviver/reviver.star
[2] https://luci-analysis.appspot.com/help#combining-issues
[3] https://luci-analysis.appspot.com/help#splitting-issues

Why LUCI Analysis posted this comment: https://luci-milo.appspot.com/ui/tests/help#policy-activated (Policy ID: builds-failed-due-to-flaky-tests)

I also experience the same issue.
The issue did not exist in #132.0.6834.159 for me.
But in #133.0.6943.53 and #133.0.6943.98 the issue appears.

Regarding the screencast from above I have 2 theories:
1) Maybe the first instance of Chromium used to do the screen capture keeps the settings alive. The bug only occurs for me after closing all instance of chromium
2) Maybe the bug was introduced after #133.0.6943.0

The following steps have been done on Ubuntu 22.04.5 LTS with chromium installed from snap:

My Steps
=======
1) Install fresh chromium
2) Go to chrome://settings/searchEngines and see that all presets exist
3) Close and reopen chromium
4) Go back to chrome://settings/searchEngines and see that all Search Engines and Site Search options except the default search got wiped
5) Create a new site search option
6) Close and reopen chromium
7) Go back to chrome://settings/searchEngines and see that the custom Site Search was wiped again

Here is a screencast of how it looks like on my machine (I close all chromium instances).

I started investigating this because of a downstream report[1] originally filed against M133. I added logging[2] to keyword_table.cc (which otherwise is a really silent file) and indeed stderr tells me those entries are being deleted right at every new Chromium start because the hashes are deemed invalid, as I get

--->
[232937:233022:0305/121815.834817:WARNING:keyword_table.cc(627)] !invalid hash for URL{google:baseURL}search?q={searchTerms}&{google:RLZ}{google:originalQueryForSuggestion}{google:assistedQueryStats}{google:searchFieldtrialParameter}{google:language}{google:prefetchSource}{google:searchClient}{google:sourceId}{google:contextualSearchVersion}ie={inputEncoding}
[232937:233022:0305/121815.834845:WARNING:keyword_table.cc(627)] !invalid hash for URLhttp://lp.com/{searchTerms}
[232937:233022:0305/121815.834853:WARNING:keyword_table.cc(301)] xDB0: Requesting removal of keyword with ID2
[232937:233022:0305/121815.834864:WARNING:keyword_table.cc(720)] xDB2: Removing keyword with id: 2
[232937:233022:0305/121815.834935:WARNING:keyword_table.cc(301)] xDB0: Requesting removal of keyword with ID3
[232937:233022:0305/121815.834942:WARNING:keyword_table.cc(720)] xDB2: Removing keyword with id: 3
<---

I don't know what is the cause for that, I'm hoping the Chromium developers will have some insight. I also think the logging would be useful  it after putting it in shape (probably replacing with VLOG instead of LOG(WARNING)), if I get to fetch the whole repository with my feeble Internet connection anyway.

[1]https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/2096844
[2]https://git.launchpad.net/~nteodosio/chromium-browser/tree/patches/l.patch?h=log-keyw-removal