# Reply 3: the derivable identity exists, and it narrows the REST check rather than closing it Written 2026-08-03, responding to `copy question conceded, REST fix has a hole, three refusals are two`. Short version: readiness versus refusal is right and I am taking it as written. The open question about deriving cluster identity from the connection is answerable, and I measured it. The answer is a partial yes that changes the shape of the argument: the case you said the REST check does not catch turns out to be caught by the platform, loudly, without us doing anything. ## Taken as written **Three refusals are two.** The distinction is the right one and I did not have it: two are statements that the configuration contradicts itself, which time cannot fix, and one can fail while the configuration is perfectly correct. Grouping them made the count look like a cost when part of it was a different thing wearing the same clothes. **Readiness rather than refusal for the probe.** Fatal on errors that retrying cannot fix, unhealthy-and-retry on timeouts and connection failures. This gets the early loud failure where it is deserved and stops coupling startup to a cold serverless cluster, which is the tier we are actually on. It also dissolves my own objection about changing the startup contract: startup no longer depends on the database being awake, only serving does, and that was already true. **The caveat about partial versus general misconfiguration.** Worth stating once in the note, as you say. An operator who copies everything passes every check we have described. That is a limit on the claim, not an argument against the checks. ## The measured answer to the open question A cluster-derived identifier is readable over the SQL connection, but it is not the cluster id. ``` CURRENT_USER() = 4NZWAUvddx1vfPd.workato_ingest@% cluster id = 10036201305668697556 ``` TiDB Cloud Serverless requires a per-cluster prefix on the SQL user name. It is derived from the cluster and is not the cluster id, so comparing it against a template's declared `cluster` would need a translation only the management API can do. On the question as you asked it, the answer is no: REST cannot compare its template targets against where it is actually connected without buying the dependency we are both trying to avoid. ## But the case you said it misses is caught anyway Your second case was: copy the whole deployment configuration, change only `TIDB_HOST`, and every check passes while the real target is somewhere else. I tested it. Same region, different gateway, same credentials: ``` ERROR 1105 (HY000): Access denied. Please check your user name and password. See .../select-cluster-tier#user-name-prefix ``` Different region, same credentials: identical error. Prefix removed from the user name: ``` ERROR 1105 (HY000): Missing user name prefix. ``` The prefix binds the credential to one cluster. So changing only the host does not silently land you on a different cluster; it fails to authenticate. The divergence you were worried about is not available on this platform, because the credential and the target are not independently settable. Two limits on that, stated so it is not read as more than it is. It is a property of TiDB Cloud Serverless user naming, not of our code, so it can change without us noticing, and it does not hold for a deployment using minted credentials against a tier without the prefix requirement. And it means the failure is at connect time rather than at boot, so with a readiness-based probe it surfaces as unhealthy rather than as a refusal, which is the correct handling but is later and quieter than a boot refusal would be. ## What this does to the REST check It narrows what the check is for, and I think that is worth saying plainly rather than quietly keeping the check at its old billing. The declared cluster id in REST configuration now covers one case: **a template file copied onto a deployment whose configuration was written fresh**, where the declared id and the template's id disagree, or a template declares a cluster and the deployment declares nothing. That case is real and the check is cheap, so I would keep it. It does not cover, and should not be described as covering, a wholesale copy. The platform covers the specific sub-case we worried about, and nothing covers an operator who copies everything onto a cluster that happens to accept the same credentials. So the note should say: the check verifies an operator's assertion against a template's assertion. Where they disagree it refuses. It does not verify either against reality, and on this platform it does not need to for the host-swap case, because the credential already does. ## Where we are E as originally written, required field, plus: - refuse at boot: BYO credential with more than one distinct declared target - refuse at boot: a template declares a cluster and the REST deployment has no cluster identity to compare it against - readiness rather than refusal: BYO reachability, fatal only on errors retrying cannot fix - deregister tools bound to an unavailable target where the transport allows it, error-shape where it does not - document that these catch partial misconfiguration, not a wholesale copy, and that the SQL user prefix is what actually prevents a host swap from reaching another cluster I do not have an open item left that I think should block implementation. The remaining uncertainties are ones we would learn more about by building it than by continuing here: whether deregistration is available on both transports, and whether the readiness split is as clean in practice as it is on paper when a cold cluster and a wrong password both arrive as a failed connection.