councilforeconed / interactive-activities

Council for Economic Education
http://interactives.councilforeconed.org
Mozilla Public License 2.0
6 stars 2 forks source link

Pizza productivity: Production graphs differ between chefs #155

Closed cbujara closed 8 years ago

cbujara commented 8 years ago

We ran into two instances today when the productivity graph showed different results for different chefs working in the same room. In both instances, two chefs saw a graph showing completion of 2 pizzas in round 4, and the other two chefs saw 1 pizza completed in round 4. Testing local instance of bocoup-2015 branch on 4 different machines.

jugglinmike commented 8 years ago

If you still have access to that activity room (i.e. if you haven't re-started the server since running that test), could you send the report to me (by visiting the "Manage Room" page and click "Download Report")?

cbujara commented 8 years ago

Here you go. Same group as for #154 and #156, BTW. report.zip

jugglinmike commented 8 years ago

I've made a theory of how this could happen based on reading the source code. Currently, the moment the game is over, all clients transition to the "endgame report" view and render a chart according to the game's state at that moment. It's possible that state changes have not fully propagated to all clients at this point, though, so that initial rendering may be out-of-date.

I was unable to reproduce the bug by forcing those conditions manually, so to be honest, I'm not convinced this is root cause of the original issue. But I was able to demonstrate the issue by scripting the conditions (hacking up the application source code itself):

diff --git a/src/activities/pizza/client/components/main/main.js b/src/activities/pizza/client/components/main/main.js
index a3de775..17a5b11 100644
--- a/src/activities/pizza/client/components/main/main.js
+++ b/src/activities/pizza/client/components/main/main.js
@@ -58,7 +59,20 @@ define(function(require) {
       // Schedule future changes to the game state to be reflected in the
       // layout.
       this.listenTo(this.gameState, 'roundStart', this.handleRoundStart);
-      this.listenTo(this.gameState, 'complete', this.handleComplete);
+      this.listenTo(this.gameState, 'complete', function() {
+
+        if (window.MIKE) {
+          console.log('setting and saving');
+          this.gameState.get('pizzas').at(0)
+            .set('foodState', 'olives')
+            .save();
+        }
+
+        setTimeout(function() {
+          console.log('handling completion');
+          this.handleComplete();
+        }.bind(this), 0);
+      });

       this.playerModel.set('isReady', true).save();

That's probably more technical than is necessary, but it is basically just configuring one client to complete the first pizza at the last moment of the final round.

So even though this is an extremely artifiial method for reproducing the bug, it is a reliable way to vet solutions to a real problem. And there's some hope that this is the same problem that you experienced--notice that the discrepancy is with the final round (my theory would not account for discrepancies from any other round).

I'm proposing a solution with gh-159.

cbujara commented 8 years ago

This issue appears to be resolved. Nice work!