log.getChildLogEntries() does not return child log entries

[Walther]

Bug report for garden internals, not directly user-facing but could affect some log-related behaviors externally too.

On the log class, the getChildLogEntries() method only returns this.entries, which contains the entries of the current log instance only:

garden/core/src/logger/log-entry.ts

Lines 404 to 406 in 08f0ef2

	getChildLogEntries() {
	return this.entries
	}

In order to actually get entries from possible child logs, you need to use getAllLogEntries() which fetches the entries from the root log.

Found when working on #4381, as the provider initialization logs did not appear in getLogMessages(garden.log), because the provider initialization code creates its own sub-log, and the sub-log is not correctly fetched within the getChildLogEntries() method called from getLogMessages()

[eysi09]

This is actually the intended behaviour.

getAllLogEntries, as the name suggests, gets all log entries for that logger.

getChildLogEntries, gets the entries that belong to that specific log context. I.e., its "child" entries. The nomenclature comes from the time when the logger was a proper graph structure you could traverse.

I thought the name was clear enough so I intentionally didn't change it, but we can of course do so if this causes confusion. I think we do need to fix that getLogMessages function though and have it use getAllLogEntries().

[Walther]

Gotcha, thanks!
Would you mind if I do the following:

• make all these relevant edits in the PR test(terraform): run tests for multiple tf versions #4381 where these were needed - even if technically this kind of changes could/should be done as a separate PR
• remove the getRootLogMessages function I added in that PR to work around the issue
• edit getLogMessages to use getAllLogEntries instead of getChildLogEntries, even if this means various test cases might get more logs back than before
• rename getChildLogEntries to getLogEntries, as it only gets entries from the current log context you are calling the method on (as there is no graph anymore, and therefore no child logs to fetch messages from)

Any objections or suggestions for alternatives?

[Walther]

The following changes were made in this PR #4381

• clarify the docstring on getLogMessages() and mention it only gets messages from the given context
• add a separate getRootLogMessages() function which gets all log messages via the root log
• rename getChildLogEntries to getLogEntries and add a docstring describing its behavior, in similar wording as the other functions around it