Bifrost Integration Chat — 2026-03-11 (Wednesday)
Channel: #forsyt-bm-integration (Suntech Innovation Slack)
Bhargav — 3:33 AM
How does Bifrost signal unsettlement?
I assumed PLACED snapshot (matching “fully override existing snapshot” from docs), but if it’s a different mechanism, we may need a small adjustment.
The resettlement path via BetOutcome (higher version, different outcome) already worked. It was the VOID-with-null-pnl that was blocking it.
Michael Cheremuhin — 3:51 AM
we have the following flows:
- bet level. individual bets can be voided or unvoided, followed by bet snapshot with updated bet status. if market (and bet) is already settled - we will also send bet outcome snapshot
- market level. if market moves out from SETTLED status - it means the whole market is unsettled (for further resettlement) and all market bets should become unsettled dropping existing outcomes (you can use market book message timestamp to filter bets outcomes). once market is settled again we will send updated market status and updated bets outcomes
Michael Cheremuhin — 3:53 AM
something separate - our team is AI friendly and we use it for internal development. if your team can share current prompt/context for bifrost integration, we can review it and suggest adjustments before they pain in production
Thread (3 replies):
Bhargav — 12:18 PM We give context from your docs and build our integration docs with other modules.
Then we build, test, deploy with few ai workflows and ship for testing to you.
Bhargav — 12:19 PM We can catch up on a call and discuss more during prod api call meeting.
Bhargav — 12:20 PM We will try to compose a doc for you to see how bifrost is implemented in our system.
Bhargav — 12:09 PM
Hey Michael — bet-level void/unvoid/unsettlement and market-level unsettlement are all implemented and deployed on bhdev.forsyt.io
Badal Agrawal — 3:18 PM
@Michael Cheremuhin Any update from the conformance team?
Bhargav — 4:06 PM
@Michael Cheremuhin following up here. The production keys are critical for our deadlines and internal testing. Please expedite the process with conformance team and let us in integrate production APIs.
KK — 4:16 PM
@Bhargav We fully understand the urgency. Your request is already at the highest priority, and the team is working to get you live at the earliest. A short wait now helps prevent potential issues in production.
Badal Agrawal — 4:31 PM
Can you please add him to the slack channel. He is handling QA for forsyt. @Michael Cheremuhin
Thread (4 replies):
Michael Cheremuhin — 4:32 PM @Andriy Pravdyvyi can you please invite guest account
Bhargav — 8:15 PM @Michael Cheremuhin @Andriy Pravdyvyi a bump on this. Can you send an invite to this email?
Andriy Pravdyvyi — 8:28 PM in 5min
Andriy Pravdyvyi — 8:28 PM done
Michael Cheremuhin — 4:48 PM
@Bhargav please check the bet: request id '45f8c2c2-7bb2-477b-a9db-bbb21d26b2c0', market id '9.2280561'. market is settled from our end and bet was voided, but the voiding didn't apply on your side
Bhargav — 6:02 PM
@Michael Cheremuhin
• Update on void investigation (request_uuid:
45f8c2c2-7bb2-477b-a9db-bbb21d26b2c0):
Root cause: Our orderService and BifrostAdapter were generating separate UUIDs, so the fallback lookup by requestUuid on incoming BetSnapshots never matched. Fix deployed to bhdev — both sides now share the same UUID.
Could you re-test a void scenario?
Thread (3 replies):
Michael Cheremuhin — 6:17 PM doesn't seem to work
Michael Cheremuhin — 6:18 PM market id = 9.2280930
Michael Cheremuhin — 6:18 PM bet request id = 185ad21b-b8ea-4b40-bf73-21d4da0bf3b2
Michael Cheremuhin — 6:04 PM
let us try
Michael Cheremuhin — 6:04 PM
did you also fix markets unsettlement when status moves from SETTLED?
Badal Agrawal — 6:18 PM
@Michael Cheremuhin The case of resettlement (unsettlement) seems to be a corner case. Although we will implement it and test it, it shouldn't be a blocker for prod go-live right?
Thread (4 replies):
Michael Cheremuhin — 6:20 PM that sounds quite critical as in case of changed result you will have bets stuck with incorrect pnl. if you can add something for manual adjustment, our first line support can potentially notify you in case of resetlement but you'll have to apply that manually
Michael Cheremuhin — 6:20 PM for bets voiding post settlement it might be more complicated, but the case is quite rare
Bhargav — 6:28 PM Understood. We will do this and get back to you soon.
Can we move to prod APIs? Please don't mind we asking many times, but it's critical for us.
Michael Cheremuhin — 6:30 PM we can't test bet placement in prod api because every single bets affects our risk management. in other words, bad/test bets from you will be affecting prices adjustment for all operators. that's reason why trading is not happy to do the testing in production
Michael Cheremuhin — 7:32 PM
@Bhargav is https://bhdev.forsyt.io/ down? can you please also check if 22.525252 (Australia U19 v New Jersey Legends) event is available for us to continue testing
Thread (12 replies):
Bhargav — 9:00 PM It's working. We were doing deployments. Few questions here:
- Is event 22.525252 (Australia U19 v New Jersey Legends) still active on Bifrost staging? We see it in our Redis cache (persisted from earlier), but it hasn't come through the queue since our last restart. Want to confirm it's still available for testing.
- Can you suggest a currently active Bifrost-only event (one without a Betfair mapping) that we can use for testing? We need an event where externalIds is empty — i.e., a match that exists only on Bifrost, not cross-mapped to Betfair.
- Does the event queue re-send all active events on reconnect, or only new/updated events? After our container restarts, we hydrate from Redis but only receive new queue messages going forward. If 22.525252 finished or became inactive, we'd still have stale data in Redis.
Michael Cheremuhin — 9:07 PM
- yes, i've resent that event right now
Michael Cheremuhin — 9:08 PM 2. this event is exactly such event:
"eventId": "22.525252",
"name": "Australia U19 v New Jersey Legends",
"startTime": "2026-03-12T16:03",
"categoryId": "9.411",
"competitors": [
{
"id": "2455",
"shortName": "New Jersey Legends",
"fullName": "New Jersey Legends"
},
{
"id": "4131",
"shortName": "Australia U19",
"fullName": "Australia U19"
}
],
"externalIds": [],
"status": "",
"version": "1773243434862",
"sportId": "2"
}```
**Michael Cheremuhin** — 9:09 PM
3. we send the data stream with new updates only as we don't control which event were consumed from rabbitmq. recovery api should be used in case you face data absent in your DBs
**Michael Cheremuhin** — 9:09 PM
please confirm this event to be added so our testing team could proceed
**Bhargav** — 9:52 PM
Hi Michael — confirmed event 22.525252 (Australia U19 v New Jersey
Legends) is present in our Redis cache with market 9.2282567 "Match
Odds (Bookmaker)" and live prices for both teams. One issue: the
event has "status": "" (empty) in the queue data. Our system maps
empty status to suspended as a safety measure, which causes the
event to be filtered out from our live and upcoming fixture lists.
Could you clarify: should status: "" mean the event is
scheduled/upcoming and bettable? If so, we can adjust the mapping
for empty status (or you can resend with an explicit status like
"not_started"). Once resolved, testing can proceed — the event is
tomorrow 2026-03-12T16:03.
**Michael Cheremuhin** — 10:02 PM
event status field is deprecated as we won't support it in future. for prematch/live please use event start time. the rest of event lifecycle is controlled by available markets
**Michael Cheremuhin** — 10:03 PM
it's blank intentionally and will be removed in future releases
**Michael Cheremuhin** — 10:03 PM
can you please remove that logic and let me once we can proceed with that event
**Bhargav** — 10:36 PM
https://bhdev.forsyt.io/fixture/bfs_22.525252?sportId=27
We don't have any other markets except bookmaker odds. No fancy markets
**Bhargav** — 10:38 PM
I placed bets on the markets on all the bookmaker lay and odds on both teams. The bet acceptance feel fast now.
**Michael Cheremuhin** — 10:40 PM
perfect