upleb.uk

Public git repos — served from a NIP-34 GRASP relay at git.upleb.uk

summaryrefslogtreecommitdiff
path: root/src/purgatory/sync/context.rs
AgeCommit message (Collapse)Author
2026-02-24rename: fetch_repository_data -> ↵DanConwayDev
fetch_repository_data_{excluding,with}_purgatory The old name was ambiguous - it wasn't clear whether purgatory was included or not. The two variants are now explicitly named: - fetch_repository_data_excluding_purgatory: DB only - fetch_repository_data_with_purgatory: DB + purgatory overlay SyncContext trait method also renamed to fetch_repository_data_with_purgatory to match the free function it delegates to.
2026-02-23Merge master into 3ca0-announcements-purgatoryDanConwayDev
2026-02-23fix: re-process hot-cache maintainer announcements after git push promotionDanConwayDev
When an owner announcement is promoted from purgatory via a git push, any maintainer announcements sitting in the rejected_events_index hot cache were never re-processed. The invalidate_and_get call only existed in SyncManager::process_event_static (the nostr sync path); the git push promotion path (http -> handlers -> git::sync) had no access to the rejected_events_index at all. Thread rejected_events_index and write_policy through the git push path: - process_purgatory_announcements: after saving the promoted announcement, parse its maintainers tag and call invalidate_and_get() for each, then re-process any returned hot-cache events via admit_event + save - process_newly_available_git_data: accept optional write_policy and rejected_events_index, pass them through to process_purgatory_announcements - handle_receive_pack: accept Arc<Nip34WritePolicy> and Arc<RejectedEventsIndex>, pass them to process_newly_available_git_data - HttpService / run_server: carry the two new fields, clone into each handle_receive_pack call - main.rs: obtain rejected_events_index from sync_manager before moving it into its task; wrap write_policy in Arc for the HTTP server - RealSyncContext::process_newly_available_git_data: pass None for both new params (purgatory sync path already handles this via SyncManager::process_event_static) Also rewrite the maintainer_reprocessing integration tests to correctly exercise the hot-cache path now that announcements require git data before being released from purgatory: - Start relay_b with relay_a as bootstrap so its SyncManager syncs maintainer announcements via negentropy before the owner git push - Use push_unique_git_data_to_relay (new helper) to give each maintainer a distinct commit hash, preventing git from skipping pack transfer - Make wait_for_event_on_relay poll in a retry loop so transient timing gaps between DB write and query do not cause false negatives
2026-02-18Revert "feat: upgrade repo to Full sync and trigger PR event subscription ↵DanConwayDev
after announcement promotion" This reverts commit d76003b629a4a03dba23a8a1c41da6e4ac4c30cf.
2026-02-18feat: upgrade repo to Full sync and trigger PR event subscription after ↵DanConwayDev
announcement promotion When git data arrives for a purgatory announcement and promotes it to the database, the relay now: 1. Upgrades the announcement's sync level in RepoSyncIndex from StateOnly to Full (git/sync.rs: process_purgatory_announcements) 2. Sends AddFilters actions to SyncManager for all connected relays, using Full sync filters (Layer 2 #a/#A/#q) to subscribe to PR events (purgatory/sync/context.rs: RealSyncContext.process_newly_available_git_data) 3. For user-submitted purgatory announcements, registers the repo in RepoSyncIndex with StateOnly level and sends AddFilters to SyncManager so it discovers and connects to relays listed in the announcement tags (nostr/builder.rs: handle_announcement AcceptPurgatory path) The RealSyncContext now accepts optional repo_sync_index and sync_action_tx parameters. main.rs wires these up from SyncManager. PolicyContext gains repo_sync_index and sync_action_tx fields for the write policy path.
2026-02-18fix: break circular deadlock in sync loop by including purgatory in URL lookupDanConwayDev
The sync loop calls fetch_repository_data() to get clone URLs so it knows where to fetch git data from. Previously this only queried the database, which means an announcement still in purgatory (no git data yet) would return no clone URLs, so the sync loop could never fetch the git data needed to promote the announcement - a circular deadlock. Fix by switching to fetch_repository_data_with_purgatory() which combines database announcements with purgatory announcements. Update the trait method's doc comment to document this behaviour. The mock implementation in tests is unaffected since it returns pre-configured data rather than delegating to either function.
2026-02-13fix: revert wrong sync approach for purgatory announcementsDanConwayDev
The partial fix treating ProcessResult::Purgatory as confirmed in pending_sync_index would trigger full L2/L3 sync for purgatory announcements. Per design (decision #6), purgatory announcements should only sync state events via SyncLevel::StateOnly (not yet implemented). Ignore test_archive_read_only_creates_bare_repo until SyncLevel is implemented in Phase 3.
2026-02-13feat: implement announcement purgatory core (breaks archive sync test)DanConwayDev
Route new announcements to purgatory instead of accepting immediately. Announcements are promoted to the database when git data arrives, ensuring we only serve announcements for repos with actual content. Implemented: - AnnouncementPurgatoryEntry type and DashMap store - Route new announcements to purgatory (replacement announcements skip) - Promote announcements on git data arrival (process_purgatory_announcements) - Authorization checks purgatory announcements (fetch_repository_data_with_purgatory) - State policy uses purgatory announcements for maintainer validation - Cleanup task handles announcement expiry - Updated count()/cleanup() to 3-tuples Known broken: - test_archive_read_only_creates_bare_repo fails: sync module does not treat purgatory announcements as confirmed repos, so per-repo sync (state events, PRs) is never triggered for purgatory announcements - Announcement persistence (save/restore) not implemented - SyncLevel (StateOnly vs Full) not implemented - Soft expiry two-phase not implemented - Expiry extension on state event / git auth not wired up
2026-01-27improve loggingDanConwayDev
2026-01-27feat: implement OID retry logic for 'not our ref' errorsDanConwayDev
Add retry loop in fetch_oids that handles git's behavior of stopping at the first missing OID. When a 'not our ref' error occurs: - Parse the missing OID from stderr - Remove it from the fetch list and track it as missing - Retry with remaining OIDs until success or all OIDs exhausted This ensures we fetch all available OIDs even when some are missing from the remote, rather than failing the entire batch. Also improves error reporting: - Include URL in all error messages for easier debugging - Log stderr even when domain is already on naughty list
2026-01-23fix: improve 'not our ref' error messages and warn about multi-OID fetch bugDanConwayDev
When git fetch fails with 'upload-pack: not our ref', git stops at the first missing OID and doesn't attempt to fetch remaining OIDs. This means if we request 5 OIDs and the first is missing, we never try the other 4 (which may exist on the remote). Changes: - Parse missing OID from stderr for clearer error messages - Single OID case: 'remote missing only oid requested: <oid>' - Multi OID case: Log WARNING and indicate other OIDs weren't attempted - Identifies the bug that needs retry logic to fetch OIDs individually
2026-01-12fix: fetch full git history instead of shallow clonesDanConwayDev
Previously, purgatory sync was using '--depth=1' when fetching OIDs from remote servers. This created shallow clones with only 1-2 commits instead of the complete git history. The fix removes the '--depth=1' flag, allowing git to fetch the complete commit history chain when fetching specific commit OIDs. This is the correct behavior for GRASP - users cloning from our relay should get the full repository history. Changes: - Remove '--depth=1' from git fetch command in RealSyncContext::fetch_oids - Update comment to clarify that full history is fetched Impact: - Production repositories will now contain full git history - Users cloning from the relay will get complete commit chains - No more 'shallow' files in git repositories - May be slightly slower due to fetching more data, but correctness is prioritized Testing: - All 564 tests pass (276 unit + 288 integration) - No regressions in existing functionality Fixes issue documented in work/active-issues/shallow-git-fetch.md
2026-01-10Add naughty list for git remotes with persistent SSL/DNS errorsDanConwayDev
Implement domain-level naughty list tracking for git remotes, reusing the existing NaughtyListTracker from relay sync. This prevents repeated attempts to fetch from git domains with persistent infrastructure issues (SSL/TLS certificate errors, DNS failures). Changes: - Updated NaughtyListTracker to track both relay URLs and git domains - Added git_naughty_list field to RealSyncContext for error classification - Modified fetch_oids() to classify git fetch errors and record naughty domains - Updated sync_identifier_next_url() to filter out naughty domains during URL selection - Added git_naughty_list parameter to ThrottleManager for domain queue processing - Threaded naughty list through start_sync_loop and all sync functions - Updated all tests to pass naughty list parameter The naughty list uses 12-hour expiration (configurable) to allow domains to recover from infrastructure issues. First occurrence logs WARN, repeats log DEBUG.
2026-01-10fix: propagate git fetch errors instead of logging misleading successDanConwayDev
2026-01-09Fix sync tests after Syncing status introductionDanConwayDev
- Fix relay_connected() helper to check v >= 2 (Syncing/Connected states) - Fix unit test to use status value 3 (Connected) instead of 1 (Connecting) - Fix clippy warning: use .to_vec() instead of .iter().cloned().collect() All 61 sync integration tests now passing. All 238 unit tests passing. Clippy clean.
2026-01-09fix: MockSyncContext creates single clone tag with multiple valuesDanConwayDev
The mock was creating multiple clone tags (one per URL), which violated NIP-34 format and triggered validation errors added in commit 92bfbd3. NIP-34 specifies: single clone tag with multiple values ["clone", "https://url1.com", "https://url2.com", ...] NOT multiple clone tags: ["clone", "https://url1.com"] ["clone", "https://url2.com"] This regression caused 7 purgatory::sync::functions tests to fail because RepositoryAnnouncement::from_event() now correctly rejects announcements with multiple clone tags. Fixes: - next_url_skips_throttled_domains - next_url_skips_tried_urls - next_url_filters_our_domain - next_url_with_specific_domain - get_throttled_domains_returns_only_throttled_with_untried - sync_identifier_enqueues_throttled_domains_when_incomplete - sync_identifier_tries_multiple_urls_until_complete All 232 unit tests now pass.
2026-01-08chore: cargo fmtDanConwayDev
2026-01-07feat(sync): extract clone URLs from PR events in purgatoryDanConwayDev
Add support for extracting clone URLs from PR/PR-Update events (kind 1618/1619) during purgatory sync, per NIP-34 specification. This enables fetching PR commits from URLs specified in the PR event itself, not just from repository announcement clone URLs. Changes: - Add collect_pr_clone_urls() to SyncContext trait - Implement in RealSyncContext: extract clone tags from PR events in purgatory - Implement in MockSyncContext: configurable PR clone URLs for testing - Update sync_identifier_next_url to merge PR clone URLs with announcement URLs - Update get_throttled_domains_with_untried_urls with same merge logic - Add unit tests for PR clone URL extraction and filtering
2026-01-07Add RealSyncContext implementation for production purgatory syncDanConwayDev
Implement the production SyncContext that connects to real systems: - RealSyncContext struct holding purgatory, database, git_data_path, our_domain, and local_relay references - fetch_repository_data: delegates to git::authorization module - collect_needed_oids: collects commit hashes from state events (branches/tags) and PR events (c-tag) in purgatory - oid_exists: delegates to git::oid_exists function - fetch_oids: uses git fetch --depth=1 to retrieve specific OIDs from remote servers, running in spawn_blocking for async safety - process_newly_available_git_data: delegates to the unified function in git::sync module for consistent post-git-data processing - has_pending_events: delegates to purgatory method - find_target_repo: finds first existing owner repository on disk - our_domain: returns configured domain for clone URL filtering This enables the purgatory sync loop to use real database queries, git operations, and event processing instead of mocks.
2026-01-07Add SyncContext trait and MockSyncContext for purgatory syncDanConwayDev
Implement the abstraction layer for purgatory sync operations: - SyncContext trait: defines interface for repository data fetching, OID existence checks, git fetch operations, and event processing - ProcessResult: captures outcomes when releasing events from purgatory - MockSyncContext: test mock with builder pattern for configuring: - Clone URLs and which OIDs each URL provides - Needed OIDs (simulates purgatory state) - URL failure simulation - Fetch logging for assertions The trait uses async_trait for async method support and requires Send + Sync for use in concurrent sync operations. This abstraction enables unit testing of sync logic without I/O, while the real implementation (to be added later) will connect to actual database, git, and relay systems.