Page MenuHomePhabricator

FlowReplies is not firing in production
Closed, DeclinedPublic

Description

Flow's EventLogging, or at least FlowReplies, is not working in production. There is no console error, but it's not sending the network request. Maybe related to our editor refactoring.

If we don't want this, we should take it out.

If we keep it, we should bring it up to date and check all the paths (both implementation and schema, e.g. 'preview' and 'keep-editing') (or remove them from the schema).


We decided not to re-implement this, so if we want this data again, we will have to re-implement the instrumentation.

Details

Related Gerrit Patches:
mediawiki/extensions/Flow : masterMake FlowReplies slightly work

Event Timeline

Mattflaschen-WMF raised the priority of this task from to High.
Mattflaschen-WMF updated the task description. (Show Details)
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Hmm, it doesn't look as broken in the DB (there are some from today), but I don't see it in the network console.

mysql:research@dbstore1002.eqiad.wmnet [log]> SELECT id, timestamp, event_action FROM FlowReplies_10561344 WHERE event_action = 'initiate' ORDER BY timestamp DESC LIMIT 1;
+-------+----------------+--------------+
| id    | timestamp      | event_action |
+-------+----------------+--------------+
| 25709 | 20150420210403 | initiate     |
+-------+----------------+--------------+
1 row in set (0.00 sec)

mysql:research@dbstore1002.eqiad.wmnet [log]> SELECT id, timestamp, event_action FROM FlowReplies_10561344 WHERE event_action = 'cancel-attempt' ORDER BY timestamp DESC LIMIT 1;        
+-------+----------------+----------------+
| id    | timestamp      | event_action   |
+-------+----------------+----------------+
| 25680 | 20150420154054 | cancel-attempt |
+-------+----------------+----------------+
1 row in set (0.00 sec)

mysql:research@dbstore1002.eqiad.wmnet [log]> SELECT id, timestamp, event_action FROM FlowReplies_10561344 WHERE event_action = 'cancel-abort' ORDER BY timestamp DESC LIMIT 1;
+-------+----------------+--------------+
| id    | timestamp      | event_action |
+-------+----------------+--------------+
| 25498 | 20150419181740 | cancel-abort |
+-------+----------------+--------------+
1 row in set (0.01 sec)

mysql:research@dbstore1002.eqiad.wmnet [log]> SELECT id, timestamp, event_action FROM FlowReplies_10561344 WHERE event_action = 'cancel-success' ORDER BY timestamp DESC LIMIT 1;
+-------+----------------+----------------+
| id    | timestamp      | event_action   |
+-------+----------------+----------------+
| 24944 | 20150416182633 | cancel-success |
+-------+----------------+----------------+
1 row in set (0.02 sec)

mysql:research@dbstore1002.eqiad.wmnet [log]> SELECT id, timestamp, event_action FROM FlowReplies_10561344 WHERE event_action = 'preview' ORDER BY timestamp DESC LIMIT 1;
+-------+----------------+--------------+
| id    | timestamp      | event_action |
+-------+----------------+--------------+
| 22322 | 20150408182827 | preview      |
+-------+----------------+--------------+
1 row in set (0.05 sec)

mysql:research@dbstore1002.eqiad.wmnet [log]> SELECT id, timestamp, event_action FROM FlowReplies_10561344 WHERE event_action = 'keep-editing' ORDER BY timestamp DESC LIMIT 1;
+-------+----------------+--------------+
| id    | timestamp      | event_action |
+-------+----------------+--------------+
| 22323 | 20150408182849 | keep-editing |
+-------+----------------+--------------+
1 row in set (0.01 sec)

mysql:research@dbstore1002.eqiad.wmnet [log]> SELECT id, timestamp, event_action FROM FlowReplies_10561344 WHERE event_action = 'save-attempt' ORDER BY timestamp DESC LIMIT 1;
+-------+----------------+--------------+
| id    | timestamp      | event_action |
+-------+----------------+--------------+
| 25712 | 20150420210515 | save-attempt |
+-------+----------------+--------------+
1 row in set (0.00 sec)

mysql:research@dbstore1002.eqiad.wmnet [log]> SELECT id, timestamp, event_action FROM FlowReplies_10561344 WHERE event_action = 'save-success' ORDER BY timestamp DESC LIMIT 1;
+-------+----------------+--------------+
| id    | timestamp      | event_action |
+-------+----------------+--------------+
| 25713 | 20150420210517 | save-success |
+-------+----------------+--------------+
1 row in set (0.00 sec)
Mattflaschen-WMF set Security to None.

8 months later: Does this problem still happen? Is this still high priority?

DannyH removed a subscriber: DannyH.Dec 15 2015, 10:18 PM

We might be able to remove the FlowReplies schema. I'm not sure if we need to keep collecting this data.

Change 282841 had a related patch set uploaded (by Mattflaschen):
WIP: Make FlowReplies slightly work

https://gerrit.wikimedia.org/r/282841

@jmatazzoni @Catrope @Pginer-WMF @Neil_P._Quinn_WMF Is this data still being used, or planned to be used?

I think we originally started tracking this for "new model for indentation".

In T96620#2197840, @Mattflaschen wrote:

@jmatazzoni @Catrope @Pginer-WMF @Neil_P._Quinn_WMF Is this data still being used, or planned to be used?
I think we originally started tracking this for "new model for indentation".

I don't care much about this data FWIW, but Joe, Pau and Neil may have other opinions. As for the indentation model, I think there's agreement already that it should be revisited.

I don't care much about this data FWIW, but Joe, Pau and Neil may have other opinions. As for the indentation model, I think there's agreement already that it should be revisited.

I'm not aware of this data being used for anything. So I'm not sure which kind of conclusions can be extracted from this data, and I won't oppose removing it unless it is proven useful for something.

If we are revisiting the indentation model, I'd like us to identify which are the current issues and which is the best way to measure how much those are happening (I have no idea if the current schema could help with this). Is there a ticket about this?

The former review of the model was aimed at reducing the occurrences of arbitrarily indented conversations, which had visible effects on the boards we identified former issues on, but I don't recall data from the present schema being used.

Thanks for pointing to those tasks @Mattflaschen. I guess my concern is that these propose to move in very different directions. So I agree that clarifying the scope (i.e., refining our current goal to something more specific: "tweak the threading model in Flow to achieve X") would help.

Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptApr 19 2016, 6:10 PM

@Mattflaschen, I don't know of any current use of this data.

However, as far as I can tell, Flow doesn't have any other event logs. That means that we'll need this or something very like it if we ever want to analyze things like bounce rate, editor choice, or device use. It seems sensible to have that type of data generally even if we don't have any particular plans for it right this moment, so I vote for fixing this when we have a chance. Of course, as an analyst I would say that :)

@Catrope What do you think?

  1. Merge https://gerrit.wikimedia.org/r/282841 (no longer marked as WIP) and fix it for real later.
  2. Fix it for real now.
  3. Remove it (and back a desired schema later if we want).

The current FlowReplies schema seems reasonably useful for tracking bounce rate etc as Neil says, but it doesn't track which editor the user used, so it doesn't say anything about editor choice, so we'd probably want to add that.

I'm leaning towards #1: semi-fix it by merging that patch (and document the things that don't work somewhere, e.g. on this task), then fix it for real another time. It would be nice to have this data, but we also have too many Flow tasks on the Q4 board already, so we have to cut things.

Change 282841 merged by jenkins-bot:
Make FlowReplies slightly work

https://gerrit.wikimedia.org/r/282841

The last record (checked on 2016-05-26) is:

mysql:research@dbstore1002 [log]> SELECT max(timestamp)timestamp from FlowReplies_10561344 ;
+----------------+
| timestamp      |
+----------------+
| 20150924153331 |
+----------------+
1 row in set (0.00 sec)

Returning the ticket to Collaboration-Team-Interested; per @Mattflaschen-WMF probably some validation needs to be done for data.

Mattflaschen-WMF updated the task description. (Show Details)
Restricted Application added a project: Growth-Team. · View Herald TranscriptJul 18 2018, 7:05 PM
SBisson closed this task as Declined.Jul 20 2018, 5:05 PM

Nobody in interested in this data anymore.