This test fails or flakes on large enough n: you can't quite rely on logic that does things like

for mode in modes:
  run sql to set cluster settings for mode
  run more sql 

Because even if you're the only database client, it's possible that the cluster settings won't be what you think they are after setting them.

This has come up a few times in tests since they often test behavior against multiple cluster settings in the same session. In theory though it could also happen in real life: there are some cluster settings that are the only way to control behavior, so if you want to set them "per statement", you need to change them repeatedly.

This is probably related to the implementation of waitForSettingUpdate and/or the rangefeed consumer that propagates settings, but it's not obvious to me where the race condition is. I think ideally waitForSettingUpdate would wait until it sees a setting being propagated that's tagged as being from its own unique statement id, or we should document that just as you can't set cluster settings in a transaction or multi-statement block, you can't rely on sessions being ordered with respect to them.

Jira issue: CRDB-19212