| Age | Commit message (Collapse) | Author |
|
Fix pre-existing clippy lints:
- &PathBuf -> &Path in audit_cleanup.rs
- too_many_arguments on process_newly_available_git_data,
process_purgatory_announcements, and HttpService::new
- clone_on_copy for PublicKey (Copy type) in purgatory cleanup loop
|
|
user-submitted purgatory announcement
The test was failing because submitting an announcement directly to syncing_relay
(user-submitted, no bootstrap) leaves the announcement in purgatory with no mechanism
to trigger relay discovery - there are no existing sync connections whose batch EOSE
would fire recompute_new_sync_filters_for_relay.
Fix: start syncing_relay with source_grasp as bootstrap. The promoted announcement
syncs via L1 generic filter → purgatory (no local git data) → StateOnly subscription
→ state event → purgatory sync fetches git data → announcement promoted → SelfSubscriber
upgrades to Full → connects to mock_relay → PR event synced and promoted.
The test's primary purpose (PR event partial OID aggregation from multiple clone
URL sources) is fully preserved.
|
|
The tests now correctly reflect the actual purgatory behavior:
1. Announcement goes to purgatory (StateOnly) - not immediately accepted
2. State event goes to purgatory
3. Git push promotes announcement to Full and releases state event
4. PR event is sent AFTER announcement promotion (accepted since repo is Full)
5. PR commit push releases PR event from purgatory
This matches the design: announcements require git data validation before
being promoted to the database, which means PR events can only be accepted
for repos with promoted announcements.
Also routes relay stdout to /tmp/relay-{port}.log for easier debugging.
|
|
- Replace KIND_REPOSITORY_ANNOUNCEMENT with Kind::GitRepoAnnouncement
- Replace KIND_REPOSITORY_STATE with Kind::RepoState
- Replace KIND_PR with Kind::GitPullRequest
- Replace KIND_PR_UPDATE with Kind::GitPullRequestUpdate
- Replace KIND_USER_GRASP_LIST with Kind::GitUserGraspList
- Replace KIND_PATCH with Kind::GitPatch
- Replace KIND_ISSUE with Kind::GitIssue
- Replace KIND_COMMENT with Kind::Comment
- Replace all Kind::Custom(30617|30618|1617|1618|1619|1621|1111|10317) patterns
- Remove all hardcoded KIND_* constants from events.rs
- Update all match statements to use Kind enum directly
- Update all filter builders to use Kind variants
- Update all test helpers and assertions
Benefits:
- Type safety: compiler prevents wrong kind numbers
- Readability: Kind::GitRepoAnnouncement is self-documenting
- Maintainability: single source of truth (rust-nostr)
- IDE support: full autocompletion and refactoring
- Standards: aligns with rust-nostr best practices
Files modified: 21
Constants removed: 9
Patterns replaced: 100+
Tests passing: 222/222
|
|
|
|
mulitple git servers
|
|
Implements test_concurrent_state_and_pr_sync which verifies that when both
a state event and a PR event for the same repository enter purgatory, both
are correctly synced from a remote relay and released when git data arrives.
The test:
1. Creates a source relay with a repo containing two commits
2. Sends both state event (referencing main branch) and PR event to source
3. Pushes git data to source relay, releasing both events from purgatory
4. Starts syncing relay that connects to source
5. Verifies both events sync to the syncing relay and are served
6. Confirms refs are correct (main branch and refs/nostr/<event-id>)
This validates that the purgatory sync mechanism handles multiple concurrent
events for the same repository without race conditions or conflicts.
|
|
|
|
Implements Phase 3 of the purgatory sync integration test plan.
Key changes:
- Add immediate sync triggering for sync-received events that go to
purgatory (instead of default 3-minute delay for user-submitted events)
- TestRelay now respects RUST_LOG environment variable for debugging
- New test verifies end-to-end flow: state event syncs from source relay,
enters purgatory, git data is fetched from source's clone URL, and
event is released and served
|
|
This test verifies the end-to-end flow where:
1. A state event is sent to the relay before git data exists
2. The event goes to purgatory (not served)
3. A git push delivers the required commits
4. The event is released from purgatory and served
This validates that process_newly_available_git_data is correctly
triggered after a git push and properly releases state events.
|