Skip to content

fix: resolve application log filenames against their directory - #26010

Open
jkmassel wants to merge 1 commit into
trunkfrom
jkmassel/fix-application-log-readfiles
Open

fix: resolve application log filenames against their directory#26010
jkmassel wants to merge 1 commit into
trunkfrom
jkmassel/fix-application-log-readfiles

Conversation

@jkmassel

@jkmassel jkmassel commented Sep 8, 2026

Copy link
Copy Markdown
Contributor

Fixes a bug where ApplicationLogDataProvider.readFiles(in:) throws on the first entry in any non-empty directory.

Found while sweeping for the URL.path() shape from #26005. Unrelated to that bug, so it's on its own.

Summary

  • contentsOfDirectory(atPath:) returns bare filenames, not paths.
  • Those names went straight to ApplicationLog(filePath:), which calls attributesOfItem(atPath:) — so the lookup resolved against the process's working directory rather than the directory that was passed in, and threw.
  • Latent. No shipping conformer calls this default implementation; WpLogDataProvider gets its logs from CocoaLumberjack's sortedLogFileInfos, which are already full paths.

Root Cause

Modules/Sources/Support/SupportDataProvider.swift

try FileManager.default.contentsOfDirectory(atPath: directory.path).compactMap { filePath in
    try ApplicationLog(filePath: filePath)
}

The closure parameter is named filePath, but contentsOfDirectory(atPath:) documents its return as "the names of the items" — a.log, not /…/logs/a.log. ApplicationLog(filePath:) is init? and throwing, and the missing-file case is the throwing one, so this doesn't degrade to an empty result — it propagates out of the compactMap and fails the whole call.

Fix

Resolve each name against directory before handing it to ApplicationLog, and rename the closure parameter to filename so the next reader isn't told it's a path.

Test plan

  • Added ApplicationLogDataProviderTests — five cases: reads every log in a directory, resolves each path against that directory, handles a filename with a space, round-trips the contents through the default readApplicationLog, and returns nothing for an empty directory.
  • Verified the tests fail without the fix.
  • WordPressTest/ApplicationLogDataProviderTests — 5/5 pass on an iOS 26.4 simulator.

The Support module has no test target of its own, so the tests live in KeystoneTests, which already imports it. Adding a target for one default implementation looked disproportionate; happy to add one if you'd rather.

readFiles(in:) passed contentsOfDirectory(atPath:) results straight to
ApplicationLog(filePath:). Those results are bare filenames, not paths, so
attributesOfItem(atPath:) could not find them and the call threw on the first
entry.

No shipping conformer calls this default implementation today, so the failure
was latent.
@jkmassel jkmassel self-assigned this Sep 8, 2026
@jkmassel jkmassel added this to the 27.3 milestone Sep 8, 2026
@wpmobilebot

Copy link
Copy Markdown
Contributor
App Icon📲 You can test the changes from this Pull Request in Jetpack by scanning the QR code below to install the corresponding build.
App NameJetpack
ConfigurationRelease-Alpha
Build Number34434
VersionPR #26010
Bundle IDcom.jetpack.alpha
Commit007e265
Installation URL0u9hdo1go8mq8
Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

@wpmobilebot

Copy link
Copy Markdown
Contributor
App Icon📲 You can test the changes from this Pull Request in WordPress by scanning the QR code below to install the corresponding build.
App NameWordPress
ConfigurationRelease-Alpha
Build Number34434
VersionPR #26010
Bundle IDorg.wordpress.alpha
Commit007e265
Installation URL30sq96o00fo80
Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants