Skip to content

fix(load): report the actual object-load status - #500

Merged
ss-o merged 1 commit into
nextfrom
bug-446
Sep 3, 2026
Merged

fix(load): report the actual object-load status#500
ss-o merged 1 commit into
nextfrom
bug-446

Conversation

@ss-o

@ss-o ss-o commented Sep 3, 2026

Copy link
Copy Markdown
Member

.zi-load-object always reported success. Every immediate load looked like it worked.

The defect

___retval+=$?
return __retval

__retval is assigned nowhere in the file. Zsh evaluates a bare name in return arithmetically, and an unset parameter is 0:

zsh -fc 'f(){ local ___retval=3; return __retval; }; f; print $?'   -> 0
zsh -fc 'f(){ local ___retval=3; return ___retval; }; f; print $?'  -> 3

The two sibling returns a few lines away use the correct three-underscore name, so this is a single missing underscore.

Why it mattered

The sole caller was already written correctly:

.zi-load-object ... $___id $___opt
integer ___last_retval=$?
___retval+=___last_retval
...
if (( ___turbo && ZI[HAVE_SCHEDULER] && 0 == ___last_retval )) {

It captures the result, accumulates it once, and gates turbo scheduling on it. A constant 0 defeated all three: a failed immediate load was counted as success, and turbo scheduling proceeded anyway.

The trap in fixing it

Returning the real status while leaving ___retval+=$? in place would have double-counted every failure, because the helper was also adding to the caller's dynamically scoped accumulator. The fix separates the two: the helper gets its own local result and returns it, and the accumulation is dropped so the caller owns it, which is the contract the caller already assumed.

Test

tests/load-object-status.zsh stubs .zi-load and .zi-load-snippet so the status under test is unambiguously the one supplied, with no dependency on a real plug-in, the network, or the filesystem. It covers plugin and snippet across success and failure, and pins that the helper leaves the caller's $___retval untouched.

Observed against the unfixed helper:

plugin failure: expected 7, got 0
not ok - .zi-load-object does not report the status of the load it performed

Registered in zsh-n.yml (both path filters and a job), since that workflow enumerates tests explicitly and an unregistered file never runs.

Full suite 19/19, zsh -n clean.

This is item 1 of the Wave 1 list in docs/maintainers/core-architecture-audit.md, preserved on the docs/core-architecture-audit branch.

Closes #446

.zi-load-object ended with

    ___retval+=$?
    return __retval

`__retval' is assigned nowhere. Zsh evaluates a bare name in `return'
arithmetically and an unset parameter is 0, so the helper always reported
success:

    zsh -fc 'f(){ local ___retval=3; return __retval; }; f; print $?'   -> 0
    zsh -fc 'f(){ local ___retval=3; return ___retval; }; f; print $?'  -> 3

The two sibling returns a few lines away use the correct three-underscore name.

The sole caller already does the right thing: it stores the result in
___last_retval, adds it to ___retval once, and gates turbo scheduling on
`0 == ___last_retval'. All of that was defeated by the constant 0, so a failed
immediate load counted as success and turbo scheduling still went ahead.

Fixing only the return would have double-counted, because the helper also added
to the caller's dynamically scoped ___retval. Give the helper its own local
result, return that, and drop the accumulation so the caller owns it, which is
the contract the caller was already written for.

tests/load-object-status.zsh stubs .zi-load and .zi-load-snippet, so the status
under test is unambiguously the one supplied. It covers plugin and snippet on
both the success and failure paths, and pins that the helper leaves the caller's
___retval alone. Against the unfixed helper it reports `plugin failure: expected
7, got 0'.

Closes #446
@ss-o
ss-o requested a review from a team as a code owner September 3, 2026 01:24
@ss-o
ss-o merged commit e18ad73 into next Sep 3, 2026
79 checks passed
@ss-o
ss-o deleted the bug-446 branch September 3, 2026 01:27
@ss-o ss-o mentioned this pull request Sep 3, 2026
13 tasks
@github-actions github-actions Bot mentioned this pull request Sep 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant