Bifrost Integration Chat — 2026-03-09 (Monday)
Channel: #forsyt-bm-integration (Suntech Innovation Slack)
Michael Cheremuhin — 3:27 PM
@Bhargav please check why lay bets are failing
Thread (2 replies):
Michael Cheremuhin — 3:27 PM 📎 image.png
Michael Cheremuhin — 3:28 PM all back bets are placing, all lay bets (any market type) are failing
Michael Cheremuhin — 3:44 PM
seems like you are now showing odds in decimal, though pnl calculation (and as reported by confromance team the settlement) is happening by harjeets
Thread (13 replies):
Michael Cheremuhin — 3:44 PM if i have this MO market:
Michael Cheremuhin — 3:44 PM 📎 image.png
Michael Cheremuhin — 3:44 PM trying to place 100 at 2.72, it shows the following:
Michael Cheremuhin — 3:45 PM 📎 image.png
Michael Cheremuhin — 3:45 PM up to you for sure to check if it's critical
Bhargav — 4:40 PM All these issues crept in because of the confusion we had with oddsType param and how we should handle these formats.
I'm trying to test the fixes. I don't see any bookmaker/sportsbook markets right now.
Michael Cheremuhin — 4:40 PM can you please use this one https://bhdev.forsyt.io/fixture/35345360?sportId=27
Bhargav — 6:43 PM @Michael Cheremuhin [ {"errorCode": "0.1001", "errorMessage": "Place bet request is not valid"}, {"errorCode": "0.1021", "errorMessage": "Bet size is less than min bet"} ]
We are getting these 2 errors when placing bets. What are the reasons for them? We don't see any min bet amount in the queue message. How can we handle the min bet amount then?
Michael Cheremuhin — 7:12 PM can you please send your placebet request so i can check the actual request, if it's failed during validation i don't have it on my end
Bhargav — 7:14 PM Request 1 (size=10 HKD): { "sportId": "2", "marketId": "9.2274534", "runnerId": 3701561, "priceIndex": 0, "size": 10, "memberSize": 10, "odds": 50, "side": "LAY", "memberCode": "572b1b26-fd8c-45e5-89c2-02093427ef37", "currency": "HKD", "ipAddress": "108.61.221.157", "requestId": "6af23a33-d77e-4415-94c6-55118939f3dc" }
Request 2 (size=20 HKD): { "sportId": "2", "marketId": "9.2274534", "runnerId": 3701561, "priceIndex": 0, "size": 20, "memberSize": 20, "odds": 48, "side": "LAY", "memberCode": "a07a6103-2ccd-4acc-8990-dc15a2c4c301", "currency": "HKD", "ipAddress": "108.61.221.157", "requestId": "f64f2f40-e59c-4c4f-84a0-2be513b39dca" }
Request 3 (size=100 HKD): { "sportId": "2", "marketId": "9.2274534", "runnerId": 3701561, "priceIndex": 0, "size": 100, "memberSize": 100, "odds": 48, "side": "LAY", "memberCode": "a07a6103-2ccd-4acc-8990-dc15a2c4c301", "currency": "HKD", "ipAddress": "108.61.221.157", "requestId": "12a788f7-b43b-4444-a82f-13057c96621d" }
All three failed with: 0.1021 "Bet size is less than min bet" + 0.1001 "Place bet request is not valid".
For comparison, this BACK request on the same market succeeded: { "sportId": "2", "marketId": "9.2274534", "runnerId": 3701561, "priceIndex": 0, "size": 10, "memberSize": 10, "odds": 46, "side": "BACK", "memberCode": "a07a6103-2ccd-4acc-8990-dc15a2c4c301", "currency": "HKD", "ipAddress": "108.61.221.157", "requestId": "a6ea14fb-01a1-4731-8762-55d91cb13cad" }
Bhargav — 7:21 PM @Michael Cheremuhin Can we get on a call and resolve the issues faster?
Michael Cheremuhin — 7:32 PM hold on please, let me check with dev team, we have ongoing release in preprod env
Bhargav — 7:48 PM Can you join the gmeet we sent on telegram? You can add your dev team as well.
Bhargav — 7:15 PM
Can you list the settlement issues that are mentioned in the telegram channel in this thread?
Bhargav — 9:52 PM
@Michael Cheremuhin Fixed the precision issues. Tested multiple bets for back and lay. Still we see some errors { "data": [ { "errorCode": "0.1021", "errorMessage": "Bet size is less than min bet" }, { "errorCode": "0.1001", "errorMessage": "Place bet request is not valid" } ] }
Michael Cheremuhin — 9:54 PM
please send the failing requests so we could check, requests failed on validation are not stored on our side
Bhargav — 9:59 PM
Failed Request #1 — LAY Karachi @ 1.0525 (16:11:14)
{ "currency": "HKD", "ipAddress": "108.61.221.157", "marketId": "9.2274534", "memberCode": "a07a6103-2ccd-4acc-8990-dc15a2c4c301", "memberSize": 10, "odds": 5.25, // ← 5.25 paise = decimal 1.0525 "priceIndex": 0, "requestId": "a2e2136e-59d9-459a-8e5a-60ef31da8007", "runnerId": 3701561, // Karachi Region Whites "side": "LAY", "size": 10, "sportId": "2" } Bifrost response: 400 → errorCode: 0.1021, "Bet size is less than min bet"
Failed Request #2 — LAY Karachi @ 1.0525 (16:13:01)
{ "currency": "HKD", "ipAddress": "108.61.221.157", "marketId": "9.2274534", "memberCode": "a07a6103-2ccd-4acc-8990-dc15a2c4c301", "memberSize": 10, "odds": 5.25, // ← same 5.25 paise "priceIndex": 0, "requestId": "efa5bfa4-576b-455c-bfc2-553ab46c8e7f", "runnerId": 3701561, // same runner "side": "LAY", "size": 10, "sportId": "2" } Bifrost response: 400 → same error
Compare with a SUCCESSFUL request — BACK Karachi @ 1.045 (16:11:08)
{ "currency": "HKD", "marketId": "9.2274534", "memberSize": 10, "odds": 4.5, // ← 4.5 paise = decimal 1.045 "runnerId": 3701561, // same runner! "side": "BACK", // ← BACK not LAY "size": 10, "sportId": "2" } Bifrost response: PENDING → PLACED → accepted
Michael Cheremuhin — 10:07 PM
will get back on that in 30 mins
Thread (12 replies):
Bhargav — 10:42 PM any updates @Michael Cheremuhin?
Michael Cheremuhin — 11:03 PM still checking @Bhargav
Bhargav — 11:11 PM Can you please list down all the issues after your tests? I'll check them early tomorrow.
Michael Cheremuhin — 11:25 PM @Bhargav all those bets should pass in now. we've decreased the min liability to 0.01 during testing
Michael Cheremuhin — 11:28 PM @Bhargav please check your side, we were doing some test bets under your account and it seems like your side went into a loop
Michael Cheremuhin — 11:28 PM 📎 image.png
Michael Cheremuhin — 11:28 PM most probably it can't handle the betsnapshot with unknown request id
Michael Cheremuhin — 11:30 PM my tests are done - 3 back bets and 3 lay bets placed. passing to conformance team to proceed with the rest of settlement and voiding. let's expect them to report back tomorrow during the day
Bhargav — 11:36 PM Okay. Thank you. Will check the loop issue.
Bhargav — 8:52 AM Are these bets placed on your internal testing tool? Is that why we don't have the request Id?
Bhargav — 9:47 AM @Michael Cheremuhin Quick follow-up on the test bets you placed — we traced what happened on our side:
Your 6 test bets (betIds 7286-7294) generated snapshot messages on forsyt.bets.snapshot.queue. Since we didn't place these bets through our platform, we had no matching order in our DB. Our consumer kept NACKing and requeuing these messages trying to find the order. Combined with the earlier orphaned betId 7240, this created an infinite loop — 10 messages cycling at ~253 msg/sec, consuming 194% CPU on our backend.
The root cause was on our side — our retry mechanism relied on the x-delivery-count header, which only works with quorum queues. Since the snapshot queue is a classic queue, the header was never set and our max-retry check never triggered. We've shipped a fix (application-level retry tracking) — messages now drop after 3 failed attempts.
Two questions for you:
- Queue type — Is there a reason forsyt.bets.snapshot.queue is a classic queue rather than a quorum queue? Quorum queues have built-in x-delivery-limit which would provide an additional safety net for exactly this scenario. Not a blocker for us (our fix handles it), just flagging as a best practice.
- External bets on our queue — When you or anyone places bets directly under our member account (outside our platform), the snapshots land on our queue. Our consumer now gracefully drops these after 3 retries. But want to confirm: are there any legitimate production scenarios where bet snapshots would arrive on our queue for bets we didn't originate? For example, does Bifrost ever generate synthetic bets, position adjustments, or system-level bets under a member account? Just want to make sure our "drop after 3 retries" logic doesn't accidentally discard something we should be processing.
Michael Cheremuhin — 1:30 PM @Bhargav you should not worry for such cases in general but i recommend to handle any kind of exceptions not to get into infinite loop as a general recommendation. production setup uses quorum queues so we should be good there as well.