Field presence and stored defaults are separate
Some client records retain availability metadata alongside their default values. The
FieldsCheckerMixin records omitted
constructor keyword fields separately from the tuple. Its base isValid() checks
whether critical fields were supplied; it does not validate their value, type or range.
The inspected concrete record also checks nested
ratings validity, so inspect overrides before interpreting that method name.
An omitted count can have a stored default of zero while remaining unavailable. A direct
decorated getter can return that default; formatField requests availability-aware
formatting and returns a placeholder for an omitted field. Explicit None counts
as supplied, yet the getter can still return a placeholder. Presence, a meaningful value and
formatted output answer different questions.
The inspected row builder uses a direct count getter and formatted getters for several other fields. Preserve the source's availability metadata when it matters; value truthiness alone cannot reconstruct it. Current-source and selected record/formatter controls establish these boundaries, without real response parsing, localization, server traffic or UI rendering.
An explicit zero price is still defined data
The client's base Money representation records which supported currency fields were supplied. Money() and Money(credits=0) are both false in a truth test, but only the second defines a credits amount. Use isDefined() for any retained currency and isCurrencyDefined(currency) for one specific field. A truth test answers whether a retained amount is nonzero, not whether price data was provided.
Illustrative Python 2.7 example of the current source contract:
from gui.shared.money import Currency, Money
price = Money(credits=0)
has_price_data = price.isDefined() # True
has_credits = price.isCurrencyDefined(Currency.CREDITS) # True
has_nonzero_amount = bool(price) # False
snapshot = price.toDict() # {'credits': 0}Serialization can change that distinction: toDict() retains an explicitly defined zero, while toSignDict() omits zero entries. Choose the representation required by the receiving UI or saved schema rather than using these methods interchangeably.
The action-price formatter uses these presence checks: after tuple conversion it supplies an explicit zero-valued Money when no currency is defined, then chooses formatted fields through currency-presence checks. Presence, nonzero value and display selection are separate decisions.
These version-sensitive representation rules do not establish affordability, currency conversion or purchase admission. Keep the owning feature's price and validation contract. The example was checked against current public Python source, not exercised as a wallet operation.
Wallet availability is separate from amount presence
Current public source; version-sensitive. The
stats requester returns zero for
actualGold and actualFreeXP when its cached
isResourcesConsumptionAllowed flag is false. The separate gold and freeXP getters clamp
negative amounts after those reads. actualCredits reads cached credits without that gate. A gold-zero field can therefore be
an availability projection rather than evidence that the underlying cached amount is zero.
Current source excerpt from the requester:
@property
def actualGold(self):
return self.getCacheValue(Currency.GOLD, 0) if self.isResourcesConsumptionAllowed else 0The condition reads the cached flag first. A false flag skips the gold lookup; a true
flag exposes the cached gold value without the ordinary getter's clamp. That lookup
supplies zero for an absent key, while a present None or negative value is
returned unchanged. These reads do not call request(), check
isSynced(), repair invalid supplied data or capture a stable multi-field
snapshot. Keep cache readiness and the consumer's value checks explicit.
actualMoney uses that gated gold getter too; its name does not promise unfiltered
balances. A defined zero in Money retains field presence, but does not recover the separate
availability condition. Preserve the status needed by the consumer alongside its amount.
The wallet controller maintains local aggregate status, initially unknown. Its syncing timeout selects unavailable and requests a warning without fetching server state or changing the cached consumption flag. Its component-status mapping repeats one status rather than checking currencies independently. Do not infer a server outage, current cached flag or transaction outcome solely from that local status.
The dialog balance view publishes
wallet.isAvailable separately from numeric model fields and listens for money,
free-XP and wallet-status updates, removing those subscriptions during finalization. Keep
pending/unavailable presentation distinct from a measured zero balance. These source
boundaries were inspected without executing wallet, timer, network, UI or native operations;
no balance loss or completed transaction is established.
An availability flag can summarize a different predicate
For a time-rental main type, Vehicle.isRentAvailable compares maxRentDuration - rentLeftTime with minRentDuration. Its stored duration bounds come from the item's time-rental packages: twice the largest package duration for the maximum, and the smallest duration for the minimum. This flag checks room for the shortest term, not every offered package.
Individual terms use isWithinMaxRentTime, which compares that capacity with the supplied package's days converted to seconds, including equality. With synthetic one- and seven-day packages, the derived maximum is fourteen days. Ten days remaining leaves capacity for one day, so the general flag passes while the seven-day check fails. Seven days remaining admits that seven-day term exactly.
The term-selection popover additionally disables time-rental rows when a current season entitlement exists. Other callers have their own gates; neither this row flag nor the capacity helper establishes affordability or server renewal permission. Preserve the package identity and consumer policy alongside a general availability value.
Selected readable duration, availability and helper checks used inert packages and remaining-time values. Package filtering, actual clocks or entitlements, prices, UI models, purchase requests and client/server runtime behavior were not exercised.
Next-expiry amounts belong to one timestamp
A reserve summary's next-expiry amount is not its complete stock or a calendar-day total. getNearestExpirationTimeAndCountForToday selects the earliest positive nextExpiryTime among the supplied boosters, then sums only expiration entries keyed by that exact timestamp. Despite its name, this helper performs no clock, date or timezone comparison.
For example, entries {100: 2, 200: 4} and {100: 3, 150: 7} produce timestamp 100 and amount 5; the later entries are excluded. These are synthetic timestamp keys. The caller controls which boosters participate: the group wrapper filters by category, resource type and limited status. Empty input returns (0, 0).
The reserve model builder publishes nextExpirationTime and nextExpirationAmount separately from depot totals and active-effect inactivation time. Keep the timestamp and amount together when projecting or comparing them. Selected readable helper checks used inert expiry records; provider inventory production, clocks, model delivery, rendering and server expiry were not exercised.