Page MenuHomePhabricator

Properly implement trace, dump, debug log support via possibly a LoggingUtils
Open, HighPublic

Description

Parsoid/JS supports a number of trace, dump, debug flags that lets us trace and debug code. It does this without requiring logging statements in the code to inspect the state of enabled flags. Parsoid/PHP needs to support similar functionality. It can do this with possibly some simple util helpers without needing to support the full complexity of powerful and generic support for log event subscribers that Parsoid/JS supports.

All public access to traceFlags, dumpFlags in $env should be removed, inspection of specific flags should be replaced by $env methods (hasTraceFlag, hasDumpFlag, etc) (currently SiteConfig provides these, but not sure they belong there), the $env->log method should delegate logging support to a LoggingUtils.

Event Timeline

ssastry created this task.May 26 2019, 5:44 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMay 26 2019, 5:44 PM
ssastry triaged this task as High priority.May 26 2019, 5:44 PM
ssastry moved this task from Backlog to Porting on the Parsoid-PHP board.
Reedy renamed this task from Properly implement trace, dump, debug log support via possibly a LoggingUtils to Properly implement trace, dump, debug log support via possibly a LoggingUtils.May 26 2019, 5:53 PM
cscott added a subscriber: cscott.May 28 2019, 3:45 PM

See https://www.mediawiki.org/wiki/Manual:How_to_debug#Creating_custom_log_groups -- mediawiki core already has a lot of logging support; hopefully we could reuse this rather than reinvent it.

See https://www.mediawiki.org/wiki/Manual:How_to_debug#Creating_custom_log_groups -- mediawiki core already has a lot of logging support; hopefully we could reuse this rather than reinvent it.

Works for me .. as long as I use the CLI "--trace tsp" flag and only see the token stream patcher log events and not every trace event. I am fine. Similarly for dump and debug flags. Nice formatting support like on the JS side would be an added bonus.

Tgr added a subscriber: Tgr.Jun 30 2019, 9:30 AM

The main difference is that Parsoid supports lazy evaluation via closures, while MediaWiki logging doesn't (neither the abstraction layer, PSR-3, nor the specific implementation used in production, Monolog). It's easy to write a Monolog processor for evaluating closures, so that seems like the most likely path forward.

Tgr added a comment.Jun 30 2019, 9:32 AM

As for granular enabling, I'd imagine we want to use channels like 'parsoid.trace.tsp' and make the channel configuration fall back to 'parsoid.trace' if unspecified. That would require some changes to Wikimedia config, but doesn't seem too difficult.

Change 529469 had a related patch set uploaded (by Subramanya Sastry; owner: Subramanya Sastry):
[mediawiki/services/parsoid@master] Env::log: Comment out functionality till T224377 is implemented

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

Change 529469 merged by jenkins-bot:
[mediawiki/services/parsoid@master] Env::log: Comment out functionality till T224377 is implemented

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

ssastry claimed this task.Wed, Sep 11, 8:17 PM

Change 536384 had a related patch set uploaded (by Subramanya Sastry; owner: Subramanya Sastry):
[mediawiki/services/parsoid@master] WIP: Implement logging support

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