With a link having a host that cannot be resolved and by running drush cron, the console outputs:
[error] Unhandled link error https://this.host.cannot.be.resolved.com has been found: cURL error 6: Could not resolve host: this.host.cannot.be.resolved.com (see https://curl.se/libcurl/c/libcurl-errors.html) for https://this.host.cannot.be.resolved.com."
The link correctly marked as being broken but logging such a message looks very depressing. It makes you think that the cron process was interrupted and didn't complete. As the scope was fulfilled, i.e., the link was correctly marked as broken, what's the purpose of filling the logs with such messages?
If cURL returned an exception while checking the link it's exactly what it’s supposed to do. It's just fulfilling its mission. It's a success, not an error.
Do not log such errors in \Drupal\linkchecker\LinkCheckerService::exceptionHandling() by default. They were caught and addressed. This should be enough, avoid flooding the logs with unnecessary entries that are only confusing the site builder.
New config option to toggle logging exception messages.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | Screenshot 2026-09-25 at 12.00.48.png | 87.69 KB | joelpittet |
| Screenshot 2026-09-25 at 11.38.31.png | 51.21 KB | claudiu.cristea |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
claudiu.cristeaComment #3
claudiu.cristeaComment #4
claudiu.cristeaComment #6
joelpittetI agree with this message (after getting some coffee in me ☕) but I think when debugging that detailed logging can be handy. So the default should be to silence them but keep that detail when someone asks for it explicitly.
Tweaked the issue summary to that end.
Comment #8
joelpittetThe MR tackles both
statusHandlingandexceptionHandling. Can you have peek @claudiu.cristeaand see if that makes this "track" better in your mind? I have been thinking similar things for ages but didn't put it into an issue as well as you.
Comment #9
joelpittetThe MR is likely to fail due to #3625969: Twig's 3.30 TypeError: Twig\Runtime\EscaperRuntime::escape(): Argument #4 ($autoescape) must be of type bool, null given BTW on functional tests
Comment #10
joelpittetAI assisted: I reviewed the output and sent it on a few iterations. Read all the messages, but didn't yet visually see where it put the checkbox. I will apply this in production and see.
Comment #11
joelpittetThe two of these might be confusing:
But the error logs have never been so clean!
Comment #12
claudiu.cristeaThe MR looks good. I still think we should not log at all. I will leave it at your discretion if we keep it configurable or just remove it.
Re #11: Maybe we can insert the word "debug". E.g., "Debug link check exceptions". I don't see the value of this logging maybe only for debugging purposes. EDIT: In this case we might want to log them to the "debug"
channellevel?Comment #13
joelpittetRE #12 Yes,
debugchannel and wording is better here. The current solution of having a second checkbox seems most correct to me, but I am hesitating because under "Log level" there is a "debug" option. And I don't want to confuse, especially if the default "all" doesn't mean "all + debug" it still would cause me to be confused.Comment #14
joelpittetRe #12/#13: Went with debug severity and no separate checkbox. Both "Unhandled link error" messages now log at
RfcLogLevel::DEBUG, so they're silent at the default log level and appear when "Log level" is set to "Debug messages". Nothing else in linkchecker logs at debug, so that option finally does something.I also relabeled "All messages (default)" to "Informational and above (default)", since it never included debug.
That should cover both the worry I had about the confusing UI and go in the direction of "don't log it at all"
Comment #15
claudiu.cristeaThank you. I've tested manually, it looks good now also in console. I like the new approach, much cleaner.
Comment #16
joelpittetThanks claudiu for the manual testing. The merge train 🚂 has left the station! This will be in the 2.2.0-rc1