Struct OrderService 

pub struct OrderService<'a> {
    pub database: &'a Arc<Database>,
    pub audit: &'a Auditor,
    pub profile: &'a Profile,
}

The order-side operations of one endpoint.

A borrowed bundle rather than an owned service: every caller already holds these — the ACME handlers in AppState, the web admin in AdminState, a background job in its own state — and building one is three references. The profile is the endpoint’s whole configuration (its signer, filter, validators and notifier), which is what makes one operation mean the same thing whichever front end reached it.

Fields

database: &'a Arc<Database>

audit: &'a Auditor

profile: &'a Profile

Implementations

impl OrderService<'_>

pub async fn new_order( &self, payload: NewOrderPayload, cached: Option<Account>, pubkey: &[u8], client_ip: Option<IpAddr>, request: &RequestContext, ) -> Result<(Order, Vec<Uuid>), Error>

Creates an order and its authorizations (RFC 8555 §7.4), for the account that signed the request.

cached is the account the JWS kid already resolved, if any. It is resolved here, after the identifiers are checked, so a malformed order is refused as malformed whoever sent it. request is where the reverse lookup that stamps the order comes from — run late, since every refusal above it would have wasted one.

pub async fn deactivate_authz( &self, authz: &mut Authorization, order: &mut Order, ) -> Result<(), Error>

Deactivates authz and re-derives its order’s status (RFC 8555 §7.5.2).

Already-deactivated is a no-op rather than an error: §7.5.2 describes the client sending the same static object to each authorization of an identifier, and a retry after a partial failure must not start reporting errors halfway through.

pub async fn claim_challenge( &self, challenge: &mut Challenge, authz: &Authorization, order: &Order, ) -> Result<ValidationClaim, Error>

Decides whether a challenge trigger (RFC 8555 §7.5.1) starts a validation, and if so claims the challenge for it.

ValidationClaim::Decided is not a refusal: the challenge is already decided — here or by a sibling — or another trigger holds the claim, and the caller answers with the challenge as it stands. challenge is refreshed where the row moved under the read, so that answer is the current object rather than the one the caller loaded. ValidationClaim::Claimed obliges the caller to follow with run_validation, and ValidationClaim::Limited is 429 rateLimited: the account has challenge.max_in_flight_per_account validations running already.

pub async fn run_validation( &self, account: &Account, challenge: &mut Challenge, authz: &mut Authorization, order: &mut Order, client_ip: Option<IpAddr>, ) -> Result<(), Error>

Validates a challenge claim_challenge claimed, and records the answer.

Either outcome is recorded — a failed validation is the challenge’s answer, not an error of this call — so Err means only that the answer could not be computed or stored. On failure the operator hears about it through challenge_failed, after the commit.

client_ip is the address the notification names: the client that triggered the validation, when there was one.

pub async fn abandon_validation( &self, challenge: &mut Challenge, authz: &mut Authorization, order: &mut Order, reason: &str, ) -> Result<(), Error>

Records a claimed validation the server has given up on.

The queue retires a row when its attempts run out or its deadline passes, and a challenge left processing at that point would be polled by its client, saying nothing, until the authorization expired. This writes the same failure run_validation writes — challenge, authorization and order together in one transaction — so the client sees an invalid order and stops.

Deliberately no challenge_failed notification: nothing was learned about the client’s own setup, which is what that event reports. The challenge_validation_abandoned log line is about this server instead.

pub async fn finalize( &self, account: &Account, order: Order, csr: &str, client_ip: Option<IpAddr>, request: &RequestContext, jobs: &JobQueue, ) -> Result<Order, Error>

Finalizes order with the base64url CSR a client sent (RFC 8555 §7.4): checks the CSR, then claims the order and queues its issuance, returning it processing. The certificate arrives when a worker has run the signer_issue job (super::issue); the client polls for it.

account must already own order (access::load_owned_order).