Inspector: attempt to detect and fix double formatting #22
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Once canalplus/rx-player#1469 is merged, we risk to be in a situation where the `timestamp [namespace] log` format as exported by the RxPaired's inspector (and can be imported by it) would be unnecessarily repeating. This is a proposal for fixing it by updating the inspector's code so we can detect and just keep the first timestamp+namespace combo To reduce the possibility of false positives and especially to avoid loss of information, I check that the "namespace" are the same. False positives are still a possibility though.
peaBerberian
force-pushed
the
misc/work-around-double-formatting1
branch
from
986b0a3 to
a441166
Compare
peaBerberian
added a commit
to canalplus/rx-player
that referenced
this pull request
Jan 8, 2025
The `__RX_PLAYER_DEBUG_MODE__` boolean -------------------------------------- The RxPlayer has a hidden feature where if a global `__RX_PLAYER_DEBUG_MODE__` boolean is declared globally and set to `true` before its code its imported, it will output debug logs. This was initially added as a mean to facilitate debugging, especially while relying on our [RxPaired](https://github.com/canalplus/RxPaired) inspector. Though we now end up communicating that trick to more people to facilitate quick checks: - applications relying on the RxPlayer which seem to have a fairly simple issue can set this to very quickly communicate us logs without having to understand our debug tools nor perform re-builds on their side. - in some scenarios, we even had users (though still in a professional context) wanting us to check why the player behaved the way it did on their devices. As those were technical people, we had no issue just telling them to set a boolean in the console and communicate to us the outputted logs. Problems with it ---------------- Logs are then generally just copy-pasted from e.g. Chrome's inspector, and as such have a lot of noise we don't need (call stack info, object structure from their own code, CORS from their applications etc.), no timestamp, and without a clear boundary between log lines vs line break in a single log. Thus, it's less convenient to us than relying on `RxPaired` or than re-building with both `LogLevel = "DEBUG"` **AND** `LogFormat = "full"`. Proposal -------- So I here propose that `RX_PLAYER_DEBUG_MODE__` also set `LogFormat` to `"full"`. This will add timestamps + a namespace to all new logs produced by the RxPlayer, then facilitating our exploitation and opening the way for easier import into RxPaired's post-debugger mode. Though to keep in mind that this will then always lead to `RxPaired`'s "double formatting" problem as exposed in canalplus/RxPaired#22. As such canalplus/RxPaired#22 or a similar work-around is a requirement before merging this. _Note that there are other solutions to fix this, like creating two global booleans, e.g. one used by RxPaired and one for users, but here I ended up preferring the ugly double formatting work-around as a lesser evil._
peaBerberian
added a commit
that referenced
this pull request
Jan 9, 2025
This is an alternative attempt (after #22) at fixing the "double formatting" situation brought by canalplus/rx-player#1469 that may be made much more frequent by canalplus/rx-player#1625. This solution fixes it client-side instead, which could be seen as arguably less ugly. The idea is to rely on the fact that the RxPlayer does full formatting by calling log functions with at least three arguments: 1. The timestamp in a string format with always numbers after a comma 2. A "namespace" (e.g. "[warn]") 3-n. The log message's arguments By considering this, we can very easily detect client-side a probable case of full formatting.
peaBerberian
added a commit
that referenced
this pull request
Jan 9, 2025
This is an alternative attempt (after #22) at fixing the "double formatting" situation brought by canalplus/rx-player#1469 that may be made much more frequent by canalplus/rx-player#1625. This solution fixes it client-side instead, which could be seen as arguably less ugly. The idea is to rely on the fact that the RxPlayer does full formatting by calling log functions with at least three arguments: 1. The timestamp in a string format with always numbers after a comma 2. A "namespace" (e.g. "[warn]") 3-n. The log message's arguments By considering this, we can very easily detect client-side a probable case of full formatting.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Once canalplus/rx-player#1469 is merged, we risk to be in a situation where the
timestamp [namespace] logformat as exported by the RxPaired's inspector (and can be imported by it) would be unnecessarily repeating.This is a proposal for fixing it by updating the inspector's code so we can detect and just keep the first timestamp+namespace combo
To reduce the possibility of false positives and especially to avoid loss of information, I check that the "namespace" are the same.
False positives are still a possibility though.