[Bug] Cloud API: 4 billing events per meter type per session (instead of 1)

[DavideMichelon10]

What happened?

When using the hosted Cloud API (api.cloud.vexa.ai), every bot session generates 4 billing events per meter type
instead of 1, resulting in being charged 4x the expected amount.

Example for a 3-minute session (fdc-asqn-hnk):

• 4× vexa_bot_minutes @ $0.0150 = $0.06
• 4× vexa_tx_addon_minutes @ $0.0100 = $0.04
• Total charged: $0.10 — expected: $0.025

All 4 events have identical minute counts and arrive within milliseconds of each other in two bursts (~3 seconds
apart).

What did you expect?

1 billing event per meter type per session:

• 1× vexa_bot_minutes
• 1× vexa_tx_addon_minutes

How to reproduce?

1. Call POST https://api.cloud.vexa.ai/bots with any Google Meet ID
2. Wait 1–2 minutes
3. Call DELETE https://api.cloud.vexa.ai/bots/google_meet/{meeting_id}
4. Download the metering CSV from the dashboard

The 4x pattern appears consistently on every session, including sessions created directly via curl with no
application code involved.

Logs / screenshots?

Date,Meter,Minutes,Cost
2026-05-11T08:24:22.620Z,vexa_tx_addon_minutes,3.00,$0.0100
2026-05-11T08:24:22.592Z,vexa_tx_addon_minutes,3.00,$0.0100
2026-05-11T08:24:22.464Z,vexa_bot_minutes,3.00,$0.0150
2026-05-11T08:24:22.412Z,vexa_bot_minutes,3.00,$0.0150
2026-05-11T08:24:22.294Z,vexa_tx_addon_minutes,3.00,$0.0100
2026-05-11T08:24:22.137Z,vexa_bot_minutes,3.00,$0.0150
2026-05-11T08:24:19.828Z,vexa_tx_addon_minutes,3.00,$0.0100
2026-05-11T08:24:19.674Z,vexa_bot_minutes,3.00,$0.0150

Version / env?

• Hosted Cloud API: api.cloud.vexa.ai
• No self-hosted components
• Tested via direct curl (no application code)
• Plan: pay-as-you-go

[DmitriyG228]

Hey @DavideMichelon10 — thanks for the detailed repro.

Confirmed root cause: post-meeting hook fires multiple times per session, propagating to 4× billing events. Fix in flight on our side (idempotency guard at the source).

We'll credit your account for the overcharge separately. Will update here once the fix ships.

[fullcircle-24]

I did a quick read of the post-meeting hook path. One reliability detail that may make the in-flight fix more durable:

fire_post_meeting_hooks builds a meeting.completed envelope without passing an explicit event id, and build_envelope defaults to a fresh UUID-backed event_id.

So if post-meeting work is entered twice for the same meeting, downstream billing sees distinct event ids unless another idempotency key is carried or source-fired state is persisted.

The regression contract I would add:

1. deterministic idempotency key for internal meeting.completed billing hooks
2. source-fired state on the meeting or an outbox table
3. pass the key through envelope/metadata so billing can dedupe too
4. test fire_post_meeting_hooks twice for the same meeting and assert one billing effect or the same idempotency key
5. test the full run_all_tasks path for duplicate terminal execution

That turns the fix from "this duplicate path is closed" into a billing reliability contract.