runHourlyScoreUpdate records score history and fires webhooks twice for every successful update

[sshdopey]

Where: src/lib/scoreUpdateCron.ts, inside the per-project success path
(lines ~58-95).

What's wrong: after a successful updateScoreForProject, the function
calls, in order:

recordScoreHistory(projectId, scoreResult.creditQuality, scoreResult.greenImpact);
triggerWebhooks({ project_id: projectId, credit_quality: ..., green_impact: ..., tx_hash: ..., timestamp: Date.now() });

// email alert logic using getHistory(projectId).slice(-2) ...

const timestamp = Date.now();
recordScoreHistory(projectId, scoreResult.creditQuality, scoreResult.greenImpact, timestamp);
triggerWebhooks({ project_id: projectId, credit_quality: ..., green_impact: ..., tx_hash: ..., timestamp });
broadcastScoreUpdate({ ... });

recordScoreHistory and triggerWebhooks are each called twice for the
exact same on-chain update — once with an implicit timestamp, once with an
explicit timestamp = Date.now() a few lines later. This reads like a
copy-paste/merge artifact (the second block also happens to be the one that
adds broadcastScoreUpdate, which is otherwise only called once).

Impact:

• Every successful hourly score update writes two entries into score
  history for the same real update (with two different timestamps a few
  milliseconds apart), corrupting trend/history queries
  (GET /v1/projects/:id/history) and any downstream analytics/forecast
  logic that assumes one entry per actual update.
• Every registered webhook subscriber receives two notifications per
  score update, with two different timestamp values, for every project,
  every hour, indefinitely.

Suggested fix: remove the first recordScoreHistory/triggerWebhooks
pair (or the second — whichever isn't needed for the interstitial
sendAlertIfSignificant delta calculation) so each successful update is
recorded and broadcast exactly once. Add a regression test asserting
recordScoreHistory/triggerWebhooks are each invoked exactly once per
successful project in runHourlyScoreUpdate.

[Alfredzee]

@Alfredzee has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I would like to work on this issue

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Alfredzee to this issue.

[Sheebazz]

@Sheebazz has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi Maintainer, I’ve reviewed the issue and I’d like to work on it. The duplicate history entries and webhook notifications look like a straightforward cleanup, but they can have a wider impact on analytics and downstream consumers.

I can trace the existing flow, remove the duplicate calls without affecting the alert logic, and add a regression test confirming each successful update records history and triggers webhooks only once.

Please consider assigning this issue to me. Thank you.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Sheebazz to this issue.

[drips-wave]

Congratulations, @Sheebazz! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @Sheebazz: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊