An unreadable confidence value is recorded as 0.0, and displaces a clean stored blob #1980

Version

Built from source at ae5de7fe (main), release line v0.10.8

Platform

macOS (Apple Silicon)

Install channel

Built from source

Binary variant

standard

What happened, and what did you expect?

strtod answers 0.0 for text it cannot read. Two places treat that answer as a real
confidence, so a property blob carrying a malformed value — "confidence":null, an empty
string, anything non-numeric — is recorded as a confidence of zero. Zero is a
meaningful value in both places, so nothing looks wrong.

The concrete harm is in src/graph_buffer/graph_buffer.c. edge_props_confidence answers
CBM_EDGE_CONF_ABSENT (-1) for an edge carrying no confidence, so that any real
confidence outranks it. The merge in edge_props_should_replace is a plain comparison:

if (inc != cur) {
    return inc > cur;
}

A malformed value answers 0.0, and 0.0 beats -1. So a blob whose confidence the code
cannot even read displaces a clean stored blob that simply carried no confidence at
all — and the stored "strategy" goes with it. The function's own doc comment already
promises the opposite behaviour.

I expected an unreadable confidence to be treated as absent, exactly as a missing one is,
so it never outranks stored data.

Reproduction

1. Index any project so at least one edge carries a confidence property.
2. Present a second property blob for the same edge whose confidence is malformed — for
   example {"confidence":null,"strategy":"x"}, or an empty string, or "high".
3. Result: the malformed blob wins the merge and replaces the stored one, taking the
   stored strategy with it. Expected: the malformed blob is treated as carrying no
   confidence, so it does not displace stored data.

The same strtod assumption appears in a second place, so a fix should cover both call
sites rather than the merge alone.

Logs

No error or warning is emitted — the malformed value is accepted as 0.0.

Diagnostics trajectory (memory / performance / leak issues)

Not applicable — a correctness issue, not memory or performance.

Project scale (if relevant)

Reproduces at any scale.

Confirmations

• I searched existing issues and this is not a duplicate.
• My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.