-
Notifications
You must be signed in to change notification settings - Fork 6
Feat/beacon manifest #581
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Feat/beacon manifest #581
Conversation
Implement GET /api/v1/beacons/manifest to build and return the full manifest JSON (language, region, tags, providers with nested topics and files, totals, checksum). Implement HEAD support with If-None-Match (304 Not Modified) and If-Match (412 Precondition Failed) for lightweight change detection during sync. Manifest versioning uses lazy evaluation: content checksum is compared with stored value on the beacon, and the version is incremented only when content actually changes. Conditional requests use the stored version directly, avoiding a full manifest build for 304/412 responses. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Introduce Beacons::RebuildManifestJob and wire it into Topics::Mutator (create, update, archive, unarchive, destroy), BeaconTopic/BeaconProvider join model callbacks, and SynchronizeCognatesOnTopicsJob so that beacon manifests stay current without waiting for a GET request. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
|
||
| # During sync, beacon sends If-Match with its current version. | ||
| # If the manifest changed since sync started, return 412 so beacon aborts and restarts. | ||
| if stale_by_match?(stored_etag) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple of checks here to protect from unnecessary rebuild
| belongs_to :beacon | ||
| belongs_to :provider | ||
|
|
||
| after_commit :rebuild_beacon_manifest, on: [ :create, :destroy ] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When we add controller/mutator for managing association, move this logic there
| belongs_to :beacon | ||
| belongs_to :topic | ||
|
|
||
| after_commit :rebuild_beacon_manifest, on: [ :create, :destroy ] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When we add controller/mutator for managing association, move this logic there
Implement GET /api/v1/beacons/manifest to build and return the full manifest JSON (language, region, tags, providers with nested topics and files, totals, checksum). Implement HEAD support with If-None-Match (304 Not Modified) and If-Match (412 Precondition Failed) for lightweight change detection during sync.
Manifest versioning uses lazy evaluation: content checksum is compared with stored value on the beacon, and the version is incremented only when content actually changes. Conditional requests use the stored version directly, avoiding a full manifest build for 304/412 responses.
What Issue Does This PR Cover, If Any?
Resolves
#566
#567
#573
What Changed? And Why Did It Change?
How Has This Been Tested?
Rspec
Please Provide Screenshots
Additional Comments
For changed associations (such as topic/providers) rebuild is triggered from callbacks now.
This logic should be later moved into controllers/mutators.