Fix action.yml severity-value mismatch, add typed events to vulnerable-contract - #1491
Merged
Gbangbolaoluwagbemiga merged 3 commits intoAug 27, 2026
Merged
Conversation
Closes HyperSafeD#1443 The min-severity input's description advertised (critical|high|medium| low|info) as accepted values, but the CLI's own SeverityLevel enum (tooling/sanctifier-cli/src/commands/analyze.rs) only implements FromStr for critical/high/medium/low — "info" isn't a real accepted value there. scripts/action_inputs.py's _ALLOWED_SEVERITIES set does accept "info" at the action-input-validation layer, so passing min-severity: info would pass that check and then fail one step later inside the actual `sanctifier analyze` invocation with "unknown severity: info" — a confusing two-stage failure for a value the action's own description told the user was valid. Didn't find any other typos/grammar issues in this file on a full read — this was the one place text and actual behavior disagreed. Left scripts/action_inputs.py's validation set unchanged since it's outside this issue's named file and the fix in action.yml already stops the misleading advertisement; happy to also tighten _ALLOWED_SEVERITIES if that's wanted as a follow-up.
Closes HyperSafeD#1445 Neither set_admin nor set_admin_secure (the only two state-changing entrypoints — fail_explicitly panics without touching storage) emitted any event, so an indexer had no way to observe an admin change on this contract other than diffing instance storage directly. Adds an AdminSetEvent #[contracttype] struct and publishes it (topic symbol_short!("admin_set")) from both functions, following the same contracttype + events().publish((topic,), data) convention already used elsewhere in this workspace (e.g. contracts/flashloan-token) rather than publishing a loose, unlabeled tuple an indexer would have to guess the shape of.
|
@springswell is attempting to deploy a commit to the gbangbolaoluwagbemiga's projects Team on Vercel. A member of the Team first needs to authorize it. |
|
@springswell Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits. You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes #1443
Closes #1445
Closes #1442
Closes #1444
action.yml typos/language.** Did a full read of
action.ymllooking for typos andgrammar issues and didn't find any literal ones — the one place text and actual behavior disagreed
was the
min-severityinput's description, which advertised(critical|high|medium|low|info)asaccepted values. The CLI's own
SeverityLevelenum(
tooling/sanctifier-cli/src/commands/analyze.rs) only implementsFromStrforcritical/high/medium/low —
infoisn't real there.scripts/action_inputs.py's_ALLOWED_SEVERITIESset does accept"info"at the action-input-validation layer, somin-severity: infowould pass that check and then fail one step later inside the actualsanctifier analyzeinvocation with"unknown severity: info"— a confusing two-stage failure fora value the action's own description told the user was valid. Fixed the description to match
reality. Left
scripts/action_inputs.py's validation set unchanged since it's outside this issue'snamed file — happy to also tighten it as a follow-up if wanted.
event emissions.** Neither
set_adminnorset_admin_secure(the only twostate-changing entrypoints in
contracts/vulnerable-contract—fail_explicitlypanics withouttouching storage) emitted any event, so an indexer had no way to observe an admin change other than
diffing instance storage directly. Adds an
AdminSetEvent#[contracttype]struct and publishes itfrom both functions, following the same
contracttype+events().publish((topic,), data)convention already used elsewhere in this workspace (e.g.
contracts/flashloan-token) rather than aloose, unlabeled tuple an indexer would have to guess the shape of.
Test plan
cargo check -p vulnerable-contractpasses clean