Server showing 409: tickets sold out when they are not

[cweitat]

Describe the bug
409 payload error message shows when booking a ticket. This can be verified by multiple users.

To Reproduce
Steps to reproduce the behaviour:

1. Go to event (https://eventyay.com/e/d99b1f7e)
2. Select 1 Free ticket and click order now
3. 409 payload error message appears

Expected behaviour
Should display the information page

Screenshots

Desktop (please complete the following information):
Firefox, Windows
Chrome, Windows

[iamareebjamal]

Ticket is sold out. Proper info should be shown in frontend

[cweitat]

@iamareebjamal ticket is not sold out. please don't jump to conclusion without asking anything

[iamareebjamal]

This is the error coming from backend. I am not jumping to any conclusion. Open the network panel and see for yourself. I never said it is not a bug. So not sure why you are triggered

So, it's a bug from server. Either way, the backend is showing tickets are sold out

[cweitat]

I'm a user, not a developer of this project. Just reporting what attendees who failed signed up are facing and not obliged to do so as well. And no one is triggered here. The short reply given earlier without any image is misleading.

So thanks for the more detailed reply of why attendees are seeing the error message.

[iamareebjamal]

We are also all volunteers here with no obligation :)

[codedsun]

@iamareebjamal Taking this up! Thanks

[codedsun]

@iamareebjamal The error is not in the attendees api else it would be failing for every event. How can i get the logs for the server? and also how can i know what values are present their in the table for this event for debugging?

[prateekj117]

@iamareebjamal While working on the New Orders API, I did had a hard time understanding the old logic for tickets left and it seemed wrong to me. It would be great if you could give it a look as well. I will get back with more details after my exam tomorrow.

[iamareebjamal]

The error is not in the attendees api

It cannot be anywhere else

else it would be failing for every event

No, it can fail for certain events where some people bought tickets and then the pending ticket holders remained from being expired

[iamareebjamal]

Well, you can see why it is broken. In order statistics API, this is how you calculate the sold tickets:

open-event-server/app/api/order_statistics/events.py

Lines 49 to 50 in 80b47a6

	completed = db.session.query(func.sum(OrderTicket.quantity.label('sum'))).join(Order.order_tickets).filter(
	Order.event_id == obj_id, Order.status == 'completed').scalar()

This returns 19

open-event-server/app/api/attendees.py

Lines 58 to 60 in 80b47a6

	# Check if the ticket is already sold out or not.
	if get_count(db.session.query(TicketHolder.id).
	filter_by(ticket_id=int(data['ticket']), deleted_at=None)) >= ticket.quantity:

This returns 50. Simply because it does not filter any expired order. So, any any ticket holder created with no deleted_at is going to be considered a valid ticket holder.

However, both logic are wrong. The first query runs:

select sum(quantity) from orders_tickets, orders where order_id = orders.id and ticket_id = 1280 and orders_tickets.deleted_at is null and orders.status = 'completed';

And returns 19, which is at least better than 50.

But it doesn't filter out deleted orders. Other example why deleted_at and multiple order state ruins the logic.

So, the actual query should be:

select sum(quantity) from orders_tickets, orders where order_id = orders.id and ticket_id = 1280 and orders_tickets.deleted_at is null and orders.status = 'completed' and orders.deleted_at is null;

Which correctly returns 18. However, orders_tickets is a redundant table and should be removed. Which order has which tickets and how many attendees is already saved in ticket_holders table.

The current tickets_holder query is:

select count(*) from ticket_holders where ticket_id = 1280 and deleted_at is null;

Which is completely wrong and doesn't take completed orders into account.

Change it to

select count(*) from ticket_holders, orders where order_id = orders.id and ticket_id = 1280 and orders.status = 'completed' and ticket_holders.deleted_at is null;

And you get the correct number 18. However, if the current logic is changed. There will be a race condition through which more tickets than allowed can be bought.

Suppose there are 10 tickets left and I buy 5 of them, but my order is not complete. In current scenario, a new attendee will see 5 tickets left and will not be able to buy more than 5, which is incorrect because my order may never be completed. So, it should be able to buy those tickets. This means, once there are 10 pending ticket holders, no one can buy new tickets even if there were 0 tickets sold.

If we change it to correct count query, then remaining tickets are 10. New attendee comes and buys 5 tickets. Another attendee 2 comes and sees remaining tickets as 10 as well because previous order is not completed. And buys 10 tickets. Now order 1 gets completed and 5 tickets remain unsold. A third attendee comes and buys those 5 tickets. Now, Order 2 gets completed, and 15 tickets have been sold when only 10 were left, and once order 3 will be completed, 20 tickets will be sold.

So, another way needs to be thought of how to mitigate that. In my opinion, the ticket reservation mechanism is dubious at best and a source of a lot of problems. At the end of the day, either it will prevent actual people to buy unsold tickets, or make them buy more tickets than allowed, or fail at the end of procedure saying that sorry, tickets are sold out.

@mariobehling Need your input