What this family covers
Nineteen named faults, all raised by State\StateError. Unlike the other families in this category, several of these are not something an operator can fix by changing a setting: this class covers this module's own database rows, its own encrypted secrets, and which WHMCS object owns which row. Where a fix exists, it is named below. Where it does not, that is stated plainly rather than guessed at.
Sealed secrets: minting, storing and reading this module's own management keys (five codes)
seal_failed means WHMCS's own encryption facility did not return usable ciphertext — retry, and report the storage region if it recurs. no_sealed_secret means nothing was ever stored for that region; re-run provisioning to mint one. decrypt_fingerprint_mismatch means the stored row was altered or partially overwritten after sealing; mint and store a fresh key rather than trust the value that came back. decrypt_empty_on_nonempty_ciphertext is the one worth remembering on its own: it is the fingerprint of WHMCS's own encryption key (cc_encryption_hash) having been rotated or restored from a different install, which makes every stored secret unreadable AT ONCE while WHMCS itself reports the failed decryption as a success. The fix is to mint a fresh management key per region, never to re-run anything against the empty value that came back. seal_empty_secret is different from the other four: it is an internal guard against ever storing a sealed empty value in the first place, and is not something a customer or operator action can trigger — if you see it, report it as a bug.
Whose row is this? (four codes, two of them internal-only)
owner_model_missing is the one you can act on: it means the product this service belongs to has no server module assigned, and the fix is on the product's Module Settings tab. owner_model_unknown and owner_shape_contradiction are internal consistency checks — the second is explicitly designed to be unreachable under this module's own logic today — and both mean WHMCS itself described something in a shape this module does not recognise; report either one rather than looking for a setting to change. owner_addon_id_missing is the addon-specific version of the same idea: an addon call arrived with no addon id at all, which should not happen in ordinary use.
An addon with nowhere for its credential, or too much bought on one row (two codes)
addon_server_context_missing is explicitly NOT a bad or missing API token, even though it looks like one: this storage addon simply has no server entry attached, so set the Server field on the addon in the client's Products/Services tab. addon_quantity_unsupported fires when an addon was ordered with a quantity above one; because one addon row can only ever back one storage account, the fix is to turn "Allow Quantity" off on the product and split the order into one row per storage account paid for. Nothing is created at the vendor while this refusal stands, so no order is ever silently part-delivered.
This module's own database tables (three codes)
schema_missing and schema_create_failed both point at the same fix: activate the hTech IDrive e2 Tools addon module (which is what creates these tables), and check the database user has CREATE privileges if it still fails. migration_not_callable means one of the module's own update files is malformed and was not run at all — reinstall the module's files rather than try to repair the database by hand.
Reading and writing this module's own state store (five codes)
binding_not_found and region_row_not_found both mean exactly what they say: run Create if a service should have a storage account, or enable the region on the service before using it. duplicate_binding is an internal consistency fault — the database's own unique key is supposed to make this impossible — and is not something to fix by picking one of the rows; report it before running anything else against the service. mirror_field_not_admin_only is a straightforward fix on the product's Custom Fields tab. mirror_write_failed is the one code in this whole family that needs no fix at all: it means the admin-visible custom fields are stale, but the storage account this module is the real system of record for is completely unaffected.