Mercurial HTTPS push continues after server password change without cache clear

Short answer

Mercurial does not proactively invalidate cached HTTPS credentials when the server-side password changes. It has no way to know the password changed; it only reacts when the server rejects a request. The typical flow is: the client sends the cached credential, the server answers 401 Unauthorized with an authentication challenge, and only then does Mercurial discard the failed credential and re-query the configured source (keyring, credential helper, or interactive prompt). Until a 401 occurs, the old credential is simply replayed.

Likely explanation vs. confirmed behavior

What is well established: HTTP authentication is stateless and challenge-driven. Mercurial sends credentials per request and treats a 401 as the signal that the credential is wrong. There is no polling of the server for password validity and no built-in TTL on cached credentials.

What is likely in your case, but worth verifying: if pushes keep succeeding after the password change, the server is probably still accepting the old credential — for example because the change hasn't propagated (replicated LDAP/AD with sync lag), the server caches authentication results itself, or the account has multiple valid credentials. Mercurial cannot succeed with a credential the server truly rejects. So if the push works, the server authorized it; the caching question is on the server side, not the client.

Conversely, if you expect the push to fail and it doesn't prompt for a new password, check whether the server returns a proper 401. Some servers or proxies return 403 or a custom error page instead, which Mercurial does not treat as "wrong password," so no re-query happens.

Answering the specific sub-questions

• Is there a setting to disable HTTPS credential caching? Not as a single toggle. Caching comes from whatever stores the credential: the in-process cache (lifetime of one hg invocation, which is short since each command is a new process), an OS keyring via a helper extension, or [auth] entries in .hgrc. To avoid persistent caching, don't configure a keyring helper and don't put passwords in .hgrc; Mercurial will then prompt per session.
• Can you force a keyring re-query before each operation? There is no native "always re-query" option. Because each hg command is a fresh process, in-memory caching is not the issue; the persistent store (keyring or .hgrc) is. The practical lever is removing or updating the stored entry.
• Should admins rely on external rotation policies? Yes. Credential lifetime enforcement belongs to the identity system (password expiry, token revocation, short-lived tokens). Mercurial is a consumer of credentials, not an enforcement point.

What to do in this case

1. Confirm what the server actually returns. Run with debug output:

   hg push --debug 2>&1 | grep -i -E "http|401|auth"

   Look for whether the request is accepted outright or challenged.
2. If you want the client to forget the credential, remove it from the OS store (Windows Credential Manager, macOS Keychain, or the relevant keyring entry) or edit the [auth] section of .hgrc. No Mercurial restart is needed beyond starting a new command.
3. If the old password still works, investigate the server: check for authentication caching, directory replication lag, or a second valid credential on the account.

Caveats

Exact behavior depends on your Mercurial version, the credential helper in use, and the server/proxy stack; the above reflects long-standing behavior but should be verified against your installation. One diagnostic detail would sharpen the recommendation: the HTTP status code the server returns for a request with the old password — that determines whether this is a client caching issue or a server acceptance issue.