Skip to content

Add a "no-op on already-paused" regression #1544

Description

@Baskarayelu

Summary

pause() twice in a row must not duplicate emitted events.

Background

Test coverage in this area is currently thin: regressions can land without a failing build. Adding the cases below will lock the contract in place, document the expected behaviour through executable examples, and shorten review cycles when this code changes again.

Acceptance criteria

  • The change matches the summary above.
  • The new test fails on the current main before the fix (if this is a regression test) and passes after.
  • Tests run on every CI matrix entry, not just the local default.
  • Lint, type-check, and tests all pass locally.
  • PR description references this issue with Closes #<this-issue>.

Implementation hints

  • Pick the right test layer: unit tests inside the affected module for pure logic, integration tests under tests/ for cross-module behaviour.
  • Cover the happy path and at least one explicit sad path; the title of this issue describes the boundary that needs to be locked in.
  • Where the project uses proptest/fast-check/fc, prefer a property test over many hand-written cases. Commit any failing seed back to the repo.
  • Keep test names assertive (returns_zero_when_balance_is_zero), not interrogative.
  • New tests should be deterministic: no Date.now()/Math.random() without an injected fake.

Repo-specific notes

  • This is a Soroban contract crate. Run cargo build --target wasm32-unknown-unknown --release to verify the change still builds for WASM.
  • Run cargo test -p <package> for the affected crate, and cargo clippy --workspace --all-targets -- -D warnings before pushing.
  • Keep #![no_std] discipline: do not introduce std:: calls; use soroban_sdk primitives.

Out of scope

  • Unrelated refactors in adjacent files.
  • Stylistic-only changes (formatting, renaming) that are not required by the fix.
  • Anything beyond the acceptance criteria above; surface follow-ups as separate issues.

How to claim and submit

  1. Comment on this issue saying you'd like to take it on; wait for a maintainer to assign you (avoids duplicated effort).
  2. Open a PR that references this issue (Closes #<this-issue>).
  3. Make sure CI is green and request review from a CODEOWNERS maintainer.
  4. PRs that close this issue and pass review may qualify for a reward — see the MAYBE REWARDED label and the GrantFox OSS campaign page.

Category: test  ·  Campaign: GrantFox OSS · Official Campaign · Maybe Rewarded

Metadata

Metadata

Labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions