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

sync: small cleanups after #69

Closed Beginner friendly
  • Is something wrong?
#83 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
82/100
Issue type
Refactor
Clarity
Clearly specified
Activity status
Active
Tech stack
rust
Domain
api, testing

Research direction

Start in crates/tern-sync/src/github.rs: the Method-to-verb match lives in UreqHttp::send, and current_keychain, current_gh and current_http hold the cfg(test) branches. Pull the mapping into a pure verb(Method) function with a unit test, and replace the unreachable-code branches with paired cfg(test) and cfg(not(test)) blocks. Move UnsetKeychain, UnsetGh, UnsetHttp and FakeGh into a cfg(test) mod test_support. Done when the new test passes, the existing 47 tests still pass, and CONTRIBUTING.md has been followed.

Written by the indexing model from the issue text.

Description

area::tern-sync kind::cleanup triage::ready
What would you like to be added?

Three follow-ups from the review of #69, all in crates/tern-sync/src/github.rs:

  • The Method → HTTP verb mapping is untested. UreqHttp::send matches Method::Post => post, Method::Patch => patch. Hand-swapping that arm leaves all 47 tests green, because UreqHttp is excluded from mutation testing. Pull the mapping into a pure fn verb(Method) -> &'static str outside the adapter, call agent.request(verb(m), url), and add a unit test.
  • current_keychain / current_gh / current_http use #[cfg(test)] if … { return } else { return } plus #[allow(unreachable_code)] on the release path. A pair of #[cfg(test)] / #[cfg(not(test))] blocks would read more clearly.
  • About 130 lines of test-only code (UnsetKeychain, UnsetGh, UnsetHttp, FakeGh) sit in github.rs. Move them to a #[cfg(test)] mod test_support so the adapter file stays about production code.
Why is this needed?

The first closes the last untested piece of the push path: nothing yet proves that creating a gist sends POST. The other two keep github.rs easy to read for the next person who touches token or push code.

Difficulty: easy. Read CONTRIBUTING.md before opening a pull request.

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

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 your-moon/tern

All issues in your-moon/tern

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.