55 lines
No EOL
4.5 KiB
Markdown
55 lines
No EOL
4.5 KiB
Markdown
# New Dash - Data issues
|
||
|
||
This is a summary of the different data issues that have been reported to the **prd-new-dash-reporting** slack channel since it’s creation on the 4th of September. It does not aim to cover the discussions on technical needs for reporting, even though these remain more or less the same requirements as 2 months ago.
|
||
|
||
It’s worth mentioning that most of the back-and-forth on the reporting needs could have been solved by having technical documentation. This was first asked by Data Team at least since the 4th of September - and we still have not received it.
|
||
|
||
# KYG Lite users migrated to New Dash broke reporting
|
||
|
||
On Thursday 12th of September the New Dashboard reporting was displaying a huge quantity of Bookings (around 3k) not attributable to New Dash. This happened because the migration of KYG Lite users was not notified to Data Team despite we already anticipated, since September the 4th, that we needed clarity on this subject. As a result, a label on the reporting was put in place until the issue was fixed:
|
||
|
||
|
||
|
||
On Friday 13th of September Ben R. created a temporary Claim called MVPMigratedUser that allow us to properly track the second batch of migrated users, and Data Team effectively hardcoded the migration date of KYG Lite users to the real migration date.
|
||
|
||
The incident was resolved on Monday 16th of September.
|
||
|
||
# First duplicated booking in BookingToProductBundle
|
||
|
||
On the 4th of October a data alert was triggered due to a duplicated booking appearing in the table BookingToProductBundle, coming from Clay’s test account.
|
||
|
||
After discussing the logic with Clay and Dagmara, it was clear that the alert raised was a miss implementation on Data side - it was the first time since the creation of the report that a user (Clay, in this case) had overridden a booking that had a Basic Screening to change to Basic Program. After this change, the logic on Data side does not allow for a Booking to appear twice in the BookingToProductBundle table if both records are supposed to be “active” - meaning, no EndDate.
|
||
|
||
# Second duplicated booking in BookingToProductBundle
|
||
|
||
On the 23th of October, another data alert was raised. In this case, it was a true duplicate since both appeared to be active at the same time (no EndDate):
|
||
|
||
|
||
|
||
After a bit of back and forth, a manual update conducted by Gus in a meeting with Uri and Daga fixed the faulty record on the 25th of October by just EndDate-ing the first created record.
|
||
|
||
# Unfixed issue on Booking duplicates
|
||
|
||
On Wednesday 30th of October, we received the same alert on duplicated bookings in BookingToProductBundle with no end date in the middle of the day after some manual test execution on Data side. This was the first day that V2 went live.
|
||
|
||
A total of 8 bookings (16 records) were faulty. All these records were created on the 30th of October, likely being linked to the tech release.
|
||
|
||
We’ve been receiving alerts in every DWH job run due to this issue until Friday 8th of November. This has reached a total of 640 duplicated records that likely affected the reliability of the data displayed in the reporting within the 30th October to Friday 8th November.
|
||
|
||
# Disappearing records in BookingToProductBundle
|
||
|
||
On Wednesday 6th of November, while re-issuing the fact that there’s a bug in production once again, Data Team noticed we had a data drift in the ingestion of data from BookingToProductBundle - DWH was containing records that didn’t exist in the backend.
|
||
|
||
After discussing the details of the backend table with Yaseen, it was clear that some records in the backend “disappeared”. An example of a Booking that missed history was studied - the user of the booking is HomeToHost account.
|
||
|
||
After investigation from Yaseen side, the potential root causes are:
|
||
|
||
> there are a number of reasons why this could have occurred, and we have been having DB issues which Ben has been investigating so suspect that was the cause. There was a release that day and that involved a webhook issue that was causing performance issues but unclear if fixing this or other changes being made by Ben resolved
|
||
>
|
||
|
||
after deep-diving more, Yaseen pointed out:
|
||
|
||
> the bookingid in your pic (931223) and all the others by that user *[HomeToHost]* were not done via KYG Application but manually via database as a workaround to a performance issue. So that may be the cause.
|
||
>
|
||
|
||
On Thursday 7th of November, Uri sends the DWH history for that user to the Dash Squad. The issue is still active at the moment of writing. |