alert condition holds [SQL0063]

A stream’s Producer().Register and Consumer(name).Register measure it against the built-in alert conditions and log every one that holds. This is the register-time pass: it reads, it never writes. No alert message lands on __system.alerts, nothing is resolved, and Register returns normally whether a condition held or not. A failed measurement does not fail Register either - it logs could not run register-time alert pass and carries on.

The alert attribute names which condition held, and alert_message, detail, and hint carry that alert’s own three lines - the same prose the scheduled check would publish. The conditions:

• partition_count - the stream’s message log is approaching the lock-table ceiling, so a Destroy or partition drop risks running out of shared memory.
• compaction_read_cost - a compacted stream’s reads are paying for superseded rows the janitor has not dropped yet.
• worker_liveness - worker rows on the stream have no live instance, so nothing is running them. Only a process running the manager claims them: sqlstreams manager run, or any Consume on the stream.

A produce-only deployment sees worker_liveness on every start, because nothing in that process runs upkeep. A process that produces and then consumes can see it once on a cold start: Register runs before Consume claims the rows, and an instance row lingers only 30 seconds past its last heartbeat, so a restart after a longer gap has nothing live to find. It clears itself.

The scheduled check is the durable half. It runs hourly under the manager, publishes an active alert to __system.alerts, and resolves it when the condition clears:

sqlstreams alert list