Skip to content

fix(runtime): propagate storage error when reading promise yield indices - #16192

Open
stedfn wants to merge 1 commit into
masterfrom
stedfn/runtime/fix-promise-yield-indices
Open

fix(runtime): propagate storage error when reading promise yield indices#16192
stedfn wants to merge 1 commit into
masterfrom
stedfn/runtime/fix-promise-yield-indices

Conversation

@stedfn

@stedfn stedfn commented Aug 10, 2026

Copy link
Copy Markdown
Contributor

action_function_call read the promise yield indices with .unwrap_or_default(), which swallows any StorageError, not just a missing key. The helper already returns the default for a genuinely absent key, so the read now propagates with ?.

No change on the absent-key path, and no protocol change.

Tests:

  • test_promise_yield_indices_missing_trie_value_not_swallowed replays a call over a proof with the indices value removed, and asserts the error reaches the caller.
  • test_promise_yield_indices_absent_key_still_applies checks a non-yield call still succeeds when the key was never written.

@codecov

codecov Bot commented Aug 10, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 73.68%. Comparing base (e65c1fe) to head (2be5e9e).
⚠️ Report is 5 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #16192      +/-   ##
==========================================
- Coverage   73.69%   73.68%   -0.01%     
==========================================
  Files         864      864              
  Lines      192209   192230      +21     
  Branches   192209   192230      +21     
==========================================
+ Hits       141642   141652      +10     
- Misses      46085    46094       +9     
- Partials     4482     4484       +2     
Flag Coverage Δ
pytests-nightly 1.20% <0.00%> (+<0.01%) ⬆️
unittests 70.05% <100.00%> (+<0.01%) ⬆️
unittests-nightly 70.13% <100.00%> (+0.02%) ⬆️
unittests-spice 66.06% <100.00%> (+0.03%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@stedfn
stedfn requested a review from Trisfald August 10, 2026 14:53
@stedfn
stedfn marked this pull request as ready for review August 10, 2026 14:53
@stedfn
stedfn requested a review from a team as a code owner August 10, 2026 14:53
@github-actions

Copy link
Copy Markdown

Pull request overview

action_function_call previously read the promise-yield indices via get_promise_yield_indices(state_update).unwrap_or_default(), which swallowed real StorageErrors (e.g. MissingTrieValue) and quietly substituted {0, 0}. The helper already handles the genuinely-absent-key path (get(...)?.unwrap_or_default() in core/store/src/utils/mod.rs:171), so switching to ? propagates storage errors while preserving the empty-state default. Two tests are added to lock in both branches.

Changes:

  • Propagate the read error at runtime/runtime/src/function_call.rs:156 with ? instead of .unwrap_or_default().
  • Add test_promise_yield_indices_missing_trie_value_not_swallowed to replay a yield call over a proof with the indices value blob removed and assert the MissingTrieValue reaches the caller.
  • Add test_promise_yield_indices_absent_key_still_applies to confirm a non-yield call still succeeds when the indices key was never written.
  • Add a small deploy_rs_contract helper.

Reviewed changes

Per-file summary
File Description
runtime/runtime/src/function_call.rs Replaces .unwrap_or_default() with ? on the PromiseYieldIndices read after successful execution.
runtime/runtime/src/tests/apply.rs Adds deploy_rs_contract helper and two tests that exercise the propagate-error and absent-key paths.

Findings

No blocking issues. The fix is well-scoped, the helper's own contract (Ok(default) for absent key) makes the change protocol-safe on the happy path, and the tests cover both the previously-swallowed error path and the honest absent-key path that the ? could plausibly regress. The hash-based targeting of the indices blob in the negative test (with rs_contract re-added to compensate for the code-recorder bypass, and missing_hash bound out of the assert_matches! arm) is a nice precaution against a false pass from unrelated omitted nodes.

✅ Approved

@greptile-apps

greptile-apps Bot commented Aug 10, 2026

Copy link
Copy Markdown

Greptile Summary

The PR stops treating storage failures while reading promise-yield indices as an empty queue, ensuring incomplete state witnesses fail validation while preserving the absent-key behavior.

  • Propagates get_promise_yield_indices storage errors from successful function calls.
  • Adds a regression test using a proof missing the indices value.
  • Adds a control test confirming a genuinely absent key still defaults and applies successfully.

Confidence Score: 5/5

The PR appears safe to merge, with the corrected error propagation and unchanged absent-key behavior covered by targeted tests.

The runtime now surfaces missing or invalid storage needed for promise-yield queue maintenance instead of silently resetting indices, while the helper continues to default only a genuinely absent key.

Reviews (1): Last reviewed commit: "fix(runtime): propagate storage error wh..." | Re-trigger Greptile

&epoch_info_provider,
Default::default(),
)
.unwrap();

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider adding an assert_matches!(apply_result.outcomes[0].outcome.status, ExecutionStatus::SuccessValue(_)); here

Otherwise if the yield call ever stops succeeding the test would pass without covering the fix

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.

2 participants