What this family covers
Twenty-two named faults, all raised by Lifecycle\LifecycleError, all about the four verbs WHMCS itself calls: Create, Suspend, Unsuspend and Terminate (plus the scheduled clean-up that follows a terminate). None of these is returned as a thrown exception to WHMCS — each one lands as text in the service's Module Command Error / tblmodulequeue.last_attempt_error, which is exactly where you should look after a failed action.
The design rule behind almost every code here: this module would rather leave a service in an unclear state that a human re-runs than report a success it did not verify. A create that cannot confirm the account exists does not mark the service Active; a suspend that cannot confirm access is cut does not mark it Suspended. That caution is why so many of these sentences begin with what the service was not marked as.
"We asked the gateway and could not get a straight answer" (four codes, one per verb)
probe_indeterminate_create, probe_indeterminate_suspend, probe_indeterminate_unsuspend and probe_indeterminate_terminate are deliberately four separate names rather than one shared "could not confirm" sentence, because the safe assumption is different for each: after an indeterminate create, assume nothing was made; after an indeterminate suspend, assume the customer can still get in; after an indeterminate unsuspend, assume they still cannot. Re-running the action is always the answer, because Create in particular converges — a second run adopts whatever the first one managed rather than duplicating it.
When the gateway DID answer, and it was the wrong answer (three codes)
probe_still_reachable fires when a suspend's confirmation probe finds the customer can still get in — the opposite of what suspending needs, so the service status is left alone rather than marked Suspended untruthfully. probe_not_reachable is its mirror during an unsuspend. probe_gateway_error is different in kind from both: the storage platform reported a fault of its own, identified by a request id — this is the platform having a problem, and must never be reported as a suspension.
Nowhere to act (four codes)
server_entry_not_found, server_entry_wrong_type, service_not_found and owner_unresolvable are all refusals to guess: either the server entry a service points at is gone or wrong, or there is no storage record for the service a scheduled task was handed, or the module could not even work out whose call this is. Each names the specific administrative fix (re-assign the server entry, correct its Type, run Create, or report it).
Terminating and the scheduled purge that follows it (seven codes)
retention_unset is the safe default speaking: no retention period configured means the account is disabled and its keys revoked, but nothing is ever automatically destroyed. purge_not_due, purge_state_not_scheduled and purge_owner_changed are all "nothing was destroyed, and correctly so" — a date not yet reached, a record never authorised for clean-up, or (rarest) the billing record's owner changing between the terminate and the scheduled purge, which this module refuses rather than risk destroying a different customer's data. purge_server_unresolved means the clean-up has no credential to act with. The last two are about a removal this module cannot confirm took effect: remove_reported_success_but_user_present means the vendor said "done" and a re-read still shows the account, and remove_unconfirmed_within_window means every scheduled re-read across the whole confirmation window still found the account present — this module has stopped waiting and is asking a human to look, rather than silently retrying forever.
The three that are about this module's own bookkeeping, not the vendor (three codes)
claim_in_flight means another pass for this exact service is already open — not a failure, just a reason a second one did not start. orphan_key_unrecognisable and convergence_read_failed are both about the "read what exists before acting" step every verb makes first: a stray management key left behind by an interrupted pass, or a read that itself failed, in which case nothing was acted on at all.
The one that is about licensing, not the vendor
new_provisioning_refused is the odd one out in this family: it fires only from Create, only from a cached Invalid licence verdict, and it is the one code here where nothing was ever attempted at the storage vendor at all. See "Licensing and activation faults" for the five ways a licence can actually fail.