feat: approve_submission emits no event, breaking off-chain indexing of proof approvals

[JamesVictor-O]

Problem

Every meaningful state transition in campaign-escrow publishes a typed event — except approve_submission, which is silent (lib.rs:432-453):

pub fn approve_submission(
    env: Env,
    business: Address,
    campaign_id: CampaignId,
    creator: Address,
) -> Result<(), Error> {
    require_not_paused(&env)?;
    business.require_auth();
    let campaign = storage::get_campaign(&env, campaign_id)?;
    if campaign.business != business {
        return Err(Error::NotCampaignOwner);
    }
    let mut application = storage::get_application(&env, campaign_id, &creator)?;
    require_not_frozen(&application)?;
    if application.status != ApplicationStatus::ProofSubmitted {
        return Err(Error::InvalidStatus);
    }
    application.proof_approved = true;
    storage::set_application(&env, &application);
    Ok(())   // no event published
}

Compare its sibling reject_submission (lib.rs:457-485), which publishes events::SubmissionRejected on the equivalent transition. contracts/campaign-escrow/src/events.rs defines events for every other transition (CampaignCreated, CampaignFunded, CreatorApplied, CreatorApproved, ProofSubmitted, SubmissionRejected, PaymentReleased, CampaignCancelled, SurplusReclaimed, ...) but nothing for a submission being approved.

Concrete failure scenario

An indexer or frontend subscribed to contract events has no way to detect "business approved this proof" — it can only see the eventual PaymentReleased once the creator claims, or has to poll get_application for every pending submission on every campaign to notice the proof_approved flip. That defeats the point of having an event-driven interface for every other transition in the same contract, and specifically breaks any UI that wants to show "your submission was approved, come claim your payment" before the creator happens to check back.

Expected behaviour

Add a SubmissionApproved { campaign_id: CampaignId, creator: Address } event (mirroring SubmissionRejected's shape) and publish it from approve_submission.

Files

• contracts/campaign-escrow/src/events.rs — add SubmissionApproved
• contracts/campaign-escrow/src/lib.rs — publish it in approve_submission

Acceptance criteria

• SubmissionApproved event added to events.rs, consistent with the existing event structs' shape/derives
• approve_submission publishes it on success
• A test asserts the event is emitted with the correct campaign_id/creator

[Ogstevyn]

Hey! This looks like a great fit for my experience. I'm a full-stack blockchain developer and I'd be happy to take this on, contribute a clean implementation, and make sure the existing functionality remains intact.

[nighshift-labs]

I checked this against tip 9da9bf51fb622232714305c4d27782ec6b175eeb. The gap is real in the current source: approve_submission persists proof_approved and returns, while reject_submission publishes its symmetric event. events.rs has no approval event, and the existing lifecycle tests exercise approval but do not assert its event payload.

The smallest patch looks like SubmissionApproved { #[topic] campaign_id: CampaignId, #[topic] creator: Address } beside SubmissionRejected, then .publish(&env) immediately after storage::set_application in approve_submission, plus a focused assertion for both topics. One caveat: the README/module comment still describe several handlers as TODOs, although this tip contains implemented lifecycle paths.

Would you like the event assertion to distinguish explicit approval from deadline-based auto-approval, or should the event cover only the explicit approve_submission call?

[grantfox-oss]

🦊 GrantFox — @Ogstevyn has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #62)
2. Your PR will be reviewed by the Ads-Bazaar maintainers

Good luck! Track your progress on GrantFox.