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

[CaptainMittens]

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.

[adfjadfj16-a11y]

Hola CaptainMittens, Muchas gracias por reportar este problema detalladamente. Hemos revisado la información proporcionada sobre el comportamiento de `strtod` y cómo afecta a la lógica de `edge_props_should_replace`. He escalado este caso al equipo de desarrollo para que analicen ambos puntos de llamada que mencionas. Te mantendremos informado a través del hilo de seguimiento en GitHub. Saludos, Joshua Richter En 31 de agosto de 2026 10:26:59 p. m. GMT-04:00, Joshua Richter ***@***.***> escribió:

…

CaptainMittens created an issue (DeusData/codebase-memory-mcp#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: ```c 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 ```text No error or warning is emitted — the malformed value is accepted as 0.0. ``` ### Diagnostics trajectory (memory / performance / leak issues) ```text Not applicable — a correctness issue, not memory or performance. ``` ### Project scale (if relevant) Reproduces at any scale. ### Confirmations - [x] I searched existing issues and this is not a duplicate. - [x] My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code. -- Reply to this email directly or view it on GitHub: #1980 You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[DeusData]

Thank you for isolating both unreadable-confidence call sites and the concrete replacement harm. Current main still has edge_props_confidence() call strtod(..., NULL), so the report is grounded. PR #1877 is the focused fix and carries negative controls for both graph-buffer replacement and trace-path evidence output. Leaving this issue open until that PR lands. Thank you for turning the shared parser shape into an atomic report.

[DeusData]

Maintainer notice: please disregard comments from @adfjadfj16-a11y on this thread

@adfjadfj16-a11y is not a maintainer of this project and does not speak for it. That account has posted replies on 17 threads here written in the project's voice — promising merges, announcing that a case has been "escalated to the development team", asking to close issues, and in some threads replying as though it were the author of someone else's pull request. None of those were maintainer decisions, and none of them carried any weight.

@DeusData is the only account that gives a maintainer response on this repository. If a comment about the fate of your issue or pull request did not come from @DeusData, it is not a decision, however official it reads.

If you were waiting on something because of one of those comments — a promised merge, a review "immediately", a request to close your ticket — I am sorry. That was noise you had no way to identify as noise, and it should not have been on your thread. Your issue or PR is judged on its own merits, and I will answer it here myself.

Nothing in this notice reflects on your contribution. Thank you for your patience, and thank you for the work.