Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Decide and test what entering a second time does

Open
  • Is something wrong?
#2 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
55/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
blockchain

Research direction

Start in enter in src/lib.rs, which writes DataKey::Member(subject) and publishes Entered without checking for an existing member, then read src/test.rs to see what is covered. Choose one repeat-entry behaviour, either keeping it or making it a no-op, and decide whether the stored ledger sequence is exposed through a getter or removed. Done means tests for the double entry and the first Entered event (topics, subject, policy_version) pass under cargo test --locked, the README states the behaviour in one sentence, and the WASM size from stellar contract build --locked is reported.

Written by the indexing model from the issue text.

Description

enhancement good first issue help wanted

Written against commit a23a8df; later commits may have moved things, so check the code first.

Size: Trivial

Description
Nothing says what happens when an address that is already a member enters again, and no test checks it. Today the second entry
is accepted, overwrites the stored record, and publishes a second Entered event. The value it overwrites is never read.

Current state
enter in src/lib.rs always runs persistent().set(&DataKey::Member(subject), &env.ledger().sequence()), extends the
lifetimes, and publishes Entered { subject, policy_version }. It never looks to see whether the address is already a member.
is_member only calls has, and no function returns the stored ledger sequence, so the value written is dead data.
src/test.rs has no test that enters twice, and none that looks at the events (env.events()), so the event's topics and
policy_version field are unchecked too.

What to build
Pick one behaviour for a repeat entry and make it explicit:

  • keep it (a repeat entry succeeds, refreshes the record and emits another event) and say so in the README and a doc comment, or
  • make it a no-op for an existing member, with no second event.

Either way, decide what the stored value is for: expose it (for example a member_since getter) or store something that does not
pretend to carry information. Then test the behaviour, and test the event once: its topics (gate, entered), the subject and
the policy_version taken from the decision.

Acceptance criteria

  • A test for entering twice that asserts the chosen behaviour, including how many events were published.
  • A test that the first entry publishes Entered with the right topics, subject and policy version.
  • The stored value is either readable through the contract's interface or removed.
  • The README says what a repeat entry does, in one sentence.
  • The gate's WASM stays small; say what size it is now.

Out of scope
Revoking membership. Counting entries.

Verification
cargo test --locked, and stellar contract build --locked for the size.

Dominant language
Rust
Stars
2
Forks
2
Avg merge
49m
Merged PRs (30d)
1

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Sorogate/example-consumer

All issues in Sorogate/example-consumer

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.