AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 45 Bitcoin

refactor(core): proper raise_if_not_confirmed behavior

Public commit record

What the developer wrote

Authored by matejcik

97/100 · Strong
refactor(core): proper raise_if_not_confirmed behavior

bd501ad8a3 renamed `raise_if_not_confirmed` to `raise_if_cancelled`,
because the function did in fact only raise when a CANCELLED result was
returned.

In practice, we want "raise if NOT CONFIRMED" behavior to cover other
unexpected results, so this PR reverts the name change and implements
the desired behavior.

[no changelog]
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This commit renames a helper function back from `raise_if_cancelled` to `raise_if_not_confirmed` and changes its behavior. Previously, the code only raised an error when the user explicitly cancelled. Now it also raises an error if the UI returns any unexpected result other than a confirmed success. This is a defensive hardening change across many on-device confirmation screens, intended to prevent the device from silently continuing when something other than a clear confirmation happens.

Recommended action

Treat as a hardening/refactor commit. Review that no caller relied on receiving a non-CONFIRMED/CANCELLED UiResult through `raise_if_not_confirmed`, since the new RuntimeError path could theoretically expose latent bugs. No immediate patch or incident response is indicated.

Security signals we found

01

Defensive validation of UI interaction results

02

Unexpected non-confirmed UI results now raise RuntimeError instead of being silently accepted

03

Broad refactor touching confirmation flows across multiple UI layouts

04

No explicit vulnerability or CVE mentioned in commit message

05

No changelog entry requested

Risk score

Why this scored 45/100

Our methodology →
Potential impact 12/30
Exploitability 8/25
Stealth signal 6/15
Affected reach 10/15
Confidence 6/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.