What
The allowance() public getter function emits an allowance_expired event when an expired allowance is queried, producing side effects in what should be a read-only view.
Why
Callers who only want to check the current allowance may inadvertently trigger event emission. This can produce duplicate events if allowance() is called multiple times for the same expired pair, or if transfer_from also triggers the same event. It violates the principle that view functions should be side-effect-free.
Scope
- Remove event emission from the
allowance() getter
- Keep the event emission in
transfer_from, burn_from, and prune_expired_allowance where it's intentional
Technical Context
- File:
contracts/learn-token/src/lib.rs (lines ~241-250)
- The
allowance() function checks expiry and emits allowance_expired before returning 0
- Other functions (
transfer_from, etc.) already emit the same event when they encounter expired allowances
Acceptance Criteria
What
The
allowance()public getter function emits anallowance_expiredevent when an expired allowance is queried, producing side effects in what should be a read-only view.Why
Callers who only want to check the current allowance may inadvertently trigger event emission. This can produce duplicate events if
allowance()is called multiple times for the same expired pair, or iftransfer_fromalso triggers the same event. It violates the principle that view functions should be side-effect-free.Scope
allowance()gettertransfer_from,burn_from, andprune_expired_allowancewhere it's intentionalTechnical Context
contracts/learn-token/src/lib.rs(lines ~241-250)allowance()function checks expiry and emitsallowance_expiredbefore returning 0transfer_from, etc.) already emit the same event when they encounter expired allowancesAcceptance Criteria
allowance()no longer emits eventstransfer_fromand other mutation functions still emitallowance_expiredwhen appropriate