pub enum UsageSource {
Leased {
lease_id: LeaseId,
fencing_token: FencingToken,
},
Overage,
}Expand description
What funded the units in a UsageEvent.
Two variants, because two things fund spend and they are validated by opposite rules. A leased charge arrives with a capability the sink checks before it touches the ledger; an overage charge has no capability to check, because no lease existed to issue one.
Making this a sum type rather than a pair of Options is deliberate. A
half-formed capability — a lease id with no token, or a token naming no
lease — is the shape a sink would have to defend against, and here it
cannot be written down. The storage schema mirrors the same constraint.
Variants§
Leased
Spent from a lease. The sink requires the stored
(lease_id, account_id, fencing_token) triple to match before the
event may change either ledger; token age relative to another active
lease is irrelevant (INVARIANTS.md GL-4).
Overage
Admitted under EnforcementMode::Elastic with no lease behind it.
It carries no lease id on purpose, and must never be given one.
Attributing unfunded spend to a real lease drives that lease’s used
past its granted, which makes reclaim’s granted - used credit
negative — a panic in the memory backend and a permanently failing
transaction in Postgres, so the account’s expired leases would never be
reclaimed again. Overage stands outside lease accounting entirely and
is funded by its own ledger term.
Implementations§
Source§impl UsageSource
impl UsageSource
Sourcepub const fn lease_id(self) -> Option<LeaseId>
pub const fn lease_id(self) -> Option<LeaseId>
The lease this charge was spent from, or None for overage.
Sourcepub const fn fencing_token(self) -> Option<FencingToken>
pub const fn fencing_token(self) -> Option<FencingToken>
The referenced lease’s capability token, or None for overage.