Summary
No response
Pain points
The current implementation of ATProtoKit lacks a centralized logging mechanism, leading to several challenges, namely that debugging is much more difficult to deal with.
To solve this, SwiftLog will be integrated into the package. Furthermore, two logging backend implementations will be used: one that maps to Apple's unified Logger framework (for Apple platforms) and one that maps to the standard SwiftLog logger.
To be more specific, log events for the methods should be added as appropriate. As an example, take a look at applyWrites():
public func applyWrites(_ repositoryDID: String,
shouldValidate: Bool? = true,
writes: [ApplyWritesUnion],
swapCommit: String?) async throws {
guard session != nil,
let accessToken = session?.accessToken else {
throw ATRequestPrepareError.missingActiveSession
}
guard let sessionURL = session?.pdsURL,
let requestURL = URL(string: "\(sessionURL)/xrpc/com.atproto.repo.applyWrites") else {
throw ATRequestPrepareError.invalidRequestURL
}
let requestBody = RepoApplyWrites(
repositoryDID: repositoryDID,
shouldValidate: shouldValidate,
writes: writes,
swapCommit: swapCommit
)
do {
let request = APIClientService.createRequest(forRequest: requestURL,
andMethod: .post,
acceptValue: nil,
contentTypeValue: "application/json",
authorizationValue: "Bearer \(accessToken)")
try await APIClientService.sendRequest(request,
withEncodingBody: requestBody)
} catch {
throw error
}
}
Various places within the method can have log events, including:
- Within the first
guard statement's else block, stating that session or accessToken doesn't have a value.
- After the
guard statement which would show the value of accessToken (albeit, obfuscated).
- Within the second
guard statement's else block, stating that there's an invalid request URL, followed by a String(describing:) of the request URL.
- After the
guard statement, which would show the value of requestURL.
- After
requestBody, which would show the values of requestBody.
- After
request, which would show the value of request.
- After the
try await code, which would say that the request has been successful.
- Within the
catch block, which gives an error log, followed by displaying the error itself.
This issue will focus on implementing log events to the ATProtoKit, ATProtoTools, and ATProtoAdmin classes. Future updates will deal with the remaining parts of the Swift package.
Considered Alternatives
No response
Is this a breaking change?
Yes
Additional Context
Summary
No response
Pain points
The current implementation of ATProtoKit lacks a centralized logging mechanism, leading to several challenges, namely that debugging is much more difficult to deal with.
To solve this,
SwiftLogwill be integrated into the package. Furthermore, two logging backend implementations will be used: one that maps to Apple's unifiedLoggerframework (for Apple platforms) and one that maps to the standardSwiftLoglogger.To be more specific, log events for the methods should be added as appropriate. As an example, take a look at
applyWrites():Various places within the method can have log events, including:
guardstatement'selseblock, stating thatsessionoraccessTokendoesn't have a value.guardstatement which would show the value ofaccessToken(albeit, obfuscated).guardstatement'selseblock, stating that there's an invalid request URL, followed by aString(describing:)of the request URL.guardstatement, which would show the value ofrequestURL.requestBody, which would show the values ofrequestBody.request, which would show the value ofrequest.try awaitcode, which would say that the request has been successful.catchblock, which gives an error log, followed by displaying the error itself.This issue will focus on implementing log events to the
ATProtoKit,ATProtoTools, andATProtoAdminclasses. Future updates will deal with the remaining parts of the Swift package.Considered Alternatives
No response
Is this a breaking change?
Yes
Additional Context
ATProtoKitclass.ATProtoAdminclass.ATProtoToolsclass.