Order of logs accros ticks

How should “two full ticks” of eating be counted for dine-in customers?

We have this scenario:

  • Group 1 orders at tick 1 and receives its food at tick 4.

  • Group 2 orders at tick 2 and receives no food before its timeout.

Our implementation currently logs Group 1 finishing eating at tick 6 (servedTick + 2) and Group 2 giving up at tick 7 (orderedTick + 5).

The intended behavior appears to be that Group 1 should finish eating within the same tick in which its two full eating ticks have elapsed. However, because the relevant events occur in different ticks, the events do not arrive in the same tick and therefore are not ordered by the within-tick rule.

Could you clarify whether, in this situation, Group 1’s FOH Finished Eating event should be logged at tick 6 or tick 7? If it is considered to have finished eating in the previous tick, should it be logged before Group 2’s Restaurant No Eating event, with no reordering because the events occur in different ticks?

Our system test, CasualTimeOutTest, passes against the reference even though it does not expect this ordering. The test expects Group 2’s Restaurant No Eating log before Group 1’s FOH Finished Eating log, while skipping tick markers, so we cannot determine the reference implementation’s exact event ticks.

Could you also explain why CasualTimeOutTest passes against the reference if the expected ordering is not supposed to be valid? We want to determine whether this indicates a timing error in our implementation or an overly restrictive ordering assertion in the test.

Once a customer has received their meal, they take 2 full ticks to eat it.

Group 1 is served at tick 4 and takes two full ticks to eat, so it finishes at tick 6.

After ordering in a restaurant, customers expect food within 4 ticks but wait for up to 5 ticks for their food to be SERVED. If they haven’t received food until then, the group leaves immediately.

Group 2 orders at tick 2 and may wait up to five ticks. Counting ticks 2–6 gives five waiting ticks, so it leaves during tick 6, not tick 7.

Since both events occur in the same tick, the specified intra-tick Eating order applies:

Customers who weren’t served for too long now leave the restaurant.
[INFO] Restaurant No Eating …

Customers start eating immediately after being served. Once they have finished eating, this will be logged.
[INFO] FOH Finished Eating …

1 Like

In a similar vein with respect to delivery groups:

“The tick when they wanted it to arrive” should be the group’s visitingTick.

So if we have a delivery group with e.g. visitingTick == 5, would we log them giving up in tick 7, 8 or 9? (assuming that no delivery driver arrived in either tick)

Also according to your logic regarding in-house groups giving up on waiting, if we stick to the same example:

If group 2 were to get its order in tick 6, would they still be there and eat it but count this as a negative experience (once they leave the restaurant)?

That is what I’m getting from your way of counting, but at the same time my group has a system test that passes against the reference implementation which seems to contradicts this.

Based on our test, it looks like the food arriving in tick 6 would not have an effect on the groups current experience, as it still counts as being within the 4-tick time window.

so we count the tick they order in as the first waitingTick?

They will give up in visitingTick + 3, so in this case, tick 8.

This will count as a neutral experience, since the food arrived, but outside the expected waiting window.

Yes, that is correct.

2 Likes