/sync command getting too much to execute

[shubham5080]

Currently sync is the important feature of the Gitcord , current solution is run the sync for the repo specific but at the end we have to run it for the all repo's so please brainstorm and suggest idea here .

[sujalgoel]

@shubham5080 webhooks honestly seem like the right fix here. instead of polling github on every sync, github just pushes events to an endpoint as they happen. one org-level webhook covers all repos. the run-once engine stops fetching from github entirely and just reads from what's already stored. /sync becomes cheap.

the tradeoff is it needs a persistent http server, not just a cron job. and you'd want a backfill strategy for the first setup. but it removes the polling problem at the root rather than patching around it.

happy to work on this if the direction makes sense.

[shubham5080]

Thanks @sujalgoel — great suggestion on #12. Org webhooks + processing events locally would tackle the real bottleneck instead of scanning every repo on /sync.

To move forward we’d need a small plan for TLS + webhook verification, handling duplicate deliveries, and backfill/reconcile when something’s missed.

If you want to drive an MVP, a short scope note or draft PR is welcome and I’ll review.

[swas3301]

Is this still open to work on? If so, I’d be interested in trying an MVP / draft PR for the webhook-based sync approach.

[shubham5080]

yes @swas3301 , No need to build the MVP -> Gitcord is already added in AOSSIE so if you have solution for issue #12 then create PR on it .

[swas3301]

I opened a first implementation slice for the webhook direction here: <PR_LINK>

It adds the secure webhook ingestion foundation:

• X-Hub-Signature-256 verification
• X-GitHub-Delivery dedupe
• mapping selected GitHub webhook payloads to existing ContributionEvent records
• optional config/docs
• tests

It does not replace /sync yet. /sync remains the backfill/reconcile path