NovA source timeout should never become a zero value
Why a temporary failure to retrieve a property value must remain an unknown state instead of turning into a numeric zero that contaminates sorting and calculations.
This article reflects the named expert’s practical perspective. See NovAsia’s editorial policy for how material is prepared and reviewed.
Zero is not an empty placeholder. It is a claim that a value is known and that the value equals zero. A timeout says almost the opposite: the system did not receive an answer in time, so the value is not currently known. Turning the second state into the first is one of those technical shortcuts that can create a very confident piece of misinformation.
The distinction is especially important for property prices and fees. A buyer can act on zero. They may sort by it, filter by it, compare it or feed it into another calculation. “Unknown” tells them to stop and verify. Those are completely different behaviours.
A transient failure is not a business value
There are several ways a value can be absent. A source may never have supplied it. A field may be intentionally not applicable. A value may have been known previously but now needs re-verification. Or an external source may simply fail to respond for a few seconds.
Those cases should not collapse into the same numeric fallback.
This topic is different from an import process turning a blank field into zero. In that case, the corruption happens while data is being transformed. With a timeout, the source may contain a perfectly valid value that the platform simply could not retrieve at that moment. The technical event is temporary; the false zero can survive much longer if it is stored, cached or propagated.
The safe product principle is straightforward: an error state should remain recognisable as an error or unknown state. It should not masquerade as a normal value merely because downstream components prefer numbers.
The visible damage may occur far from the failed request
Imagine a property price cannot be refreshed. The detail page may handle the problem well and display “price to be confirmed”. That looks honest. But somewhere else the same missing response is represented internally as zero.
The catalogue then sorts the property to the top of “lowest price first”. A budget filter includes it among genuinely low-priced options. A comparison screen calculates an absurdly low price per square metre. None of those surfaces has to display a literal “0” for the corruption to influence the buyer.
Testing a timeout only where the value is fetched is too narrow. The check needs to follow every important decision that consumes the value. A property platform reuses the same fact across many components, so the failure mode needs to travel safely too.
A missing source response should reduce certainty, not create a new bargain.
Derived calculations need to inherit uncertainty
Prices are often inputs to other figures: instalment amounts, percentages, budget summaries, price-per-area calculations or comparative totals. If the base value becomes zero, the mathematics may remain perfectly valid while the meaning collapses.
This is a particularly dangerous output because calculated numbers look authoritative. A user may see a clean total and have no clue that one input disappeared upstream.
A robust calculation should therefore be able to say, in effect, “I cannot produce this result because a required input is unavailable.” That is less visually satisfying than a number, but it preserves the boundary between known data and missing data.
The same applies to sorting and filtering. Unknown values need an explicit rule. They can be placed separately, excluded from a price-dependent filter with a clear note, or handled in another transparent way. What matters is that they do not inherit the semantic meaning of zero.
Retrying does not excuse the wrong interim state
A timeout may disappear on the next attempt. The source answers, the correct price arrives and most users never notice. That does not make the interim state irrelevant.
A product cannot assume that every retry will finish before somebody sees the page. External services fail for minutes, networks become unstable and internal dependencies occasionally slow down. A buyer can arrive during that exact interval. The temporary state is therefore part of the real user experience.
When the value returns, the interface should recover cleanly. It should not produce a fake history in which the price “changed” from zero to the real amount. If change history is exposed, a technical retrieval failure must remain distinguishable from a commercial update.
There is also a choice to make about the last known value. In some cases, it can be useful to keep showing it with a visible date and a warning that the latest verification failed. In other cases, hiding the number until it can be refreshed is safer. That decision depends on what the field means and how quickly it can become misleading. Neither option requires inventing zero.
Error wording should match what the system actually knows
A user does not need an internal incident report. They do need a status that corresponds to reality.
If the platform knows only that the current value could not be retrieved, it should not claim that the seller withdrew the price. If it knows the last confirmed value and date, it can present that history carefully. If it knows that the source is temporarily unavailable, it can say so without promising when it will return.
This is the same editorial discipline applied to technical states: do not infer beyond the evidence available.
A graceful failure can be less informative than the normal page while still being trustworthy. That is a good trade. The alternative is a complete-looking interface carrying a value that never existed.
The fix is complete only when zero disappears from every dependency
After changing this behaviour, the detail page, catalogue order, budget filters, comparison view and every calculation that reads the same field all need checking. Then I would repeat the path with the source healthy and confirm that recovery does not leave a stale warning or require an unusual manual refresh.
The product should be able to distinguish at least three meanings: the value is zero; the value is unknown; the value was known before but is not currently re-confirmed. Those states may look inconvenient in a data model, but they correspond to genuinely different buyer decisions.
For a property user, the benefit is immediate. A zero can send them towards the wrong option. An honest unknown simply tells them that one criterion is not ready for a decision yet. Exposing that uncertainty is safer than hiding a timeout behind a number that looks precise.