Since I created a thread about this as well and some interesting points where made I thought I'd take the right to quote someone making a very interesting point as to why Death Recap might be broken. Additionally as Kaisha theorized down here in this thread as well as the one I created, it might be that Death Recap does indeed work fine, but damage calculations might be so broken to the point it could be rigged. Essentially saying that the DR is a debug snapshot of what the server sees that we do not see.
[{quoted}](name=Snoozel Chu,realm=NA,application-id=3ErqAdtq,discussion-id=RRhEQf8n,comment-id=000c,timestamp=2019-04-27T23:03:37.066+0000)
I don't remember where I read this, but as a guy with rudimentary programming skills, I believe I remember hearing about DR being bugged due to what amounts to a "fetch error." And this is more plausible than ghost damage sources.
In essence, the way DR most likely works is by fetching values at death to fill categories. "Killer" and "Assist" work as you expect. This data is relatively straight forward. One shows who killed you, and the other is filled with 1 or 2 players that got assist credit. This portion of the fetch program works as intended, usually. But the rest of the values are, most likely, unaligned.
"Damage source", "Icon", "Spell name", "damage type", "Quantity of damage" are likely values the DR needs to call for display. These values are likely stored in [box] for each one. For anyone who had to take computer science in high school, a good surrogate example would be cell algorithms in Excel. A group of cells would hold values that other cells with equations would call from to fill new cells with display data. In an advanced system, the cells having the base values are filled by other cells of values. If the cells feeding values to the cells feeding the end equation have the wrong info, you get bad end cells that display the wrong numbers.
In terms of game programming, the values would likely be filled into brackets, to then be displayed into the death recap. We've all seen {}'s and such in recap, and that would be caused by bad value fetching. However, based on how the values are 'shaped', one value could be falsely extrapolated into the wrong end result. An ability could display as a summoner spell. The damage and type could be falsely portrayed, even as the server casts the right info, if the fetch program is calling things the wrong way.
An example: Garen uses his Q as part of the damage that kills you. The value for that specific ability might be {GQ1}. Physical damage might be {1} for physical. Magic as {2}, true as {0}. Again, all examples. In a perfect system, when filling the value tables for the fetch, this damage would display like this: {GQ1, 1, 250} in actually, based on the age of the system and how small riot was at conception, this would actually be more likely to display as {GQ11250}, parsed into different categories based on digit placement. It's quick and messy, but as long as the data fed to the value tables remains consistent, it works. Except it doesn't.
Riot has massively overhauled the game since launch, making a lot of changes to how things display in game. Damage pop ups, ability pop ups, lots of random things given clarity for ease of play. But if the the base data is changing to suit this new means of in game display, yet is the same data used by the old DR system, then that Garen Q could be completely misread as, say, Janna throwing her Q instead. With the addition of so many sources of of effects and damage, like from runes, and the lack of change to the old system of read the data, then the data would be read incorrectly. But as long as it matches something in the original table used by DR, something will be displayed. And it will be the wrong thing.
In order to fix this, Riot would have to find a system of data feeding from server to client that consolidates all the information needed that matches a new table programmed into DR. But, that table would need to be updated with every new content addition, with major updates taking longer to fix. This is why simply "fixing" death recall won't stick. After a couple patches, the data feeding would change enough to render the DR obsolete. The solution would be to change how the data is fed in a way that more precise and provides more that just raw values. The server would need to provide everything so that DR needs no table. But in doing so, this would increase the load on the data pipeline and cause other issues, like client latency. So this creates a lose lose situation for Riot. They either set aside man power to manually update the DR data table so that it always accurately extrapolates the raw data, and update it with every single patch; or they reprogram the sever to client data feed to provide lossless information on every detail of an ability, which will inevitably introduce lag.
Tl;Dr Riot can't fix the death recall system without either a dedicated update team with each patch, or updating server-to-client data feed for the DR to be so specific as to increase latency due to the volume of extra data being sent, should the above theory of design hold true. In order to avoid both of these problems would require a lot of technical engineering to create an "as needed" framework with a suitable load time that displays killer info a second or two after dying. Which is not an easy task, and could lead to problems and crashes if done improperly. This is a rework of a scale that would require beta testing as it affects how the server sends data and how the client reads it. And Riot would rather spend those Dev hours on new content, as the death recall is a relatively useless tool.
But again, it's just a theory, but it is more plausible than the game rigging extra damage, which is something that would effect the integrity of competitive play at high levels and would be noticed much sooner.