🇳🇿New Zealand @bomoko

Ah, thanks for pinging this thread @acbramley - this was actually fixed ages ago.

Thanks all!

bomoko → made their first commit to this issue’s fork.

Thanks all.

bomoko → made their first commit to this issue’s fork.

MR available.

bomoko → created an issue.

Great, I'll mark it as tested then

bomoko → created an issue.

Merging into the new 3.x branch

Looking good @GuillaumeG - I've pinned your changes to D10+ only, and we'll release this as a new major version.

Ah, thanks for the clarification!

I was actually testing locally capturing the udp output with nc - I wonder if there's some weirdness going on downstream.

This is what I was seeing, in terms of the difference in structure :-

Without LagoonLogsLogProcessor:

{
  "@timestamp": "2023-07-16T21:35:20.016453+00:00",
  "@version": 1,
  "host": "8b8e14550172",
  "message": "The file assets://js was not deleted because it does not exist.",
  "type": "project_unset-safe_branch_unset",
  "channel": "file",
  "level": "NOTICE",
  "monolog_level": 250
}

With LagoonLogsLogProcessor:

{
  "@timestamp": "2023-07-16T21:29:30.469535+00:00",
  "@version": 1,
  "host": "8b8e14550172",
  "message": "The file assets://js was not deleted because it does not exist.",
  "type": "project_unset-safe_branch_unset",
  "channel": "file",
  "level": "NOTICE",
  "monolog_level": 250,
  "ip": "127.0.0.1",
  "request_uri": "http://drupal10-base.docker.amazee.io/",
  "uid": 0,
  "link": "",
  "application": "drupal"
}

Which makes sense because the processor _should_ attach this arbitrary data to the log entry.

I wonder what's happening that it didn't make a difference for you between the two cases? This is the kind of mystery that keeps me up at night :D

Hi @GuillaumeG

Thanks for the MR, it's greatly appreciated.

Would you mind expanding a little on why you've removed the `LagoonLogsLogProcessor`?
Without it seems as though we're not getting a bunch of the fields that are calculated by `transformDataForProcessor`.

From my side, just to test, I've restored `LagoonLogsLogProcessor` and changed it's invoke signature to `public function __invoke(\Monolog\LogRecord $record) {` and this seems to bring the log details back in line with what the module is currently producing.

Some more info on this would be super. Thanks!

bomoko → created an issue.