Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add os_signpost logs for render() and Workflow and Worker lifecycle #1134

Merged
merged 9 commits into from May 8, 2020

Conversation

AquaGeek
Copy link
Contributor

@AquaGeek AquaGeek commented May 5, 2020

Fixes #1083

We are logging:

  • Workflow creation and destruction*
  • Worker creation and destruction*
  • Workflow render() calls
  • Sink events — note: The format strings specified for these does not include the "public" specifier, so they shouldn't show up in logs unless a debugger is attached. This is important, as you don't want to e.g. log password entry in text fields.

*Note: We're not instrumenting the Workflows or Workers themselves; we're instrumenting the infrastructure that gets created to hold onto them.

// If you don't subsequently render this workflow, it won't show up in Instruments:
let workflow = MyWorkflow()

@AquaGeek AquaGeek added enhancement New feature or request swift Affects the Swift library. labels May 5, 2020
@AquaGeek
Copy link
Contributor Author

AquaGeek commented May 5, 2020

This is what it looks like in the Tic Tac Toe sample app:

os_signpost

@AquaGeek
Copy link
Contributor Author

AquaGeek commented May 5, 2020

Testing failed:
	'init(subsystem:category:)' is only available in iOS 10.0 or newer
	'init(subsystem:category:)' is only available in iOS 10.0 or newer
	Testing cancelled because the build failed.

** TEST FAILED **

@dhavalshreyas Do we need to bump the spm tests to iOS 10?

.start { [weak self] event in
switch event {
case .value(let output):
self?.handle(output: output)
Copy link
Contributor

@JustinDSN JustinDSN May 5, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it make sense to log an event to indicate a worker emitted a value and it's about to be handled? So you would see that the worker emitted the event, and then it was mapped and handled by a sink?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe move the logging to a different function. logWorkerState(event:)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm exploring using .on(…) in the stream (similar to what .logEvents does). I'll update this soon.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did the .on(..) work out?


import os.signpost

extension OSLog {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Should this file be called OSLog+Workflow or OSLog+LogSubsystems or something other than just "Log"?

@JustinDSN JustinDSN closed this May 5, 2020
@JustinDSN JustinDSN reopened this May 5, 2020
@JustinDSN
Copy link
Contributor

Sorry about the false close, I accidentally hit the button when I tried to cancel a comment.

@dhavalshreyas
Copy link
Contributor

@dhavalshreyas Do we need to bump the spm tests to iOS 10?

Yes! Bumped it up here #1135

@dhavalshreyas
Copy link
Contributor

This is awesome @AquaGeek! Thank you for getting this in!

.start { [weak self] event in
switch event {
case .value(let output):
self?.handle(output: output)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe move the logging to a different function. logWorkerState(event:)?

swift/Workflow/Sources/SubtreeManager.swift Outdated Show resolved Hide resolved
@AquaGeek
Copy link
Contributor Author

AquaGeek commented May 6, 2020

OK. Everything is on this branch now.

I think the last open question is: should we remove the event logging (i.e. sink and worker events) or make them more generic for now? One option would be to log the related Workflow/Worker type instead of the event type (as that's essentially useless, e.g. Action).

@JustinDSN
Copy link
Contributor

JustinDSN commented May 6, 2020

OK. Everything is on this branch now.

I think the last open question is: should we remove the event logging (i.e. sink and worker events) or make them more generic for now? One option would be to log the related Workflow/Worker type instead of the event type (as that's essentially useless, e.g. Action).

I would vote for making them more generic "Action" along with a comment and a follow up task to log the more detail once we get the sign off from Mosec over removing the logging altogether.

@AquaGeek
Copy link
Contributor Author

AquaGeek commented May 7, 2020

OK. Everything is on this branch now.
I think the last open question is: should we remove the event logging (i.e. sink and worker events) or make them more generic for now? One option would be to log the related Workflow/Worker type instead of the event type (as that's essentially useless, e.g. Action).

I would vote for making them more generic "Action" along with a comment and a follow up task to log the more detail once we get the sign off from Mosec over removing the logging altogether.

To clarify, when I say remove logging I mean remove event logging (for sink events and worker outputs). All the lifecycle stuff can stay.

.start { [weak self] event in
switch event {
case .value(let output):
self?.handle(output: output)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did the .on(..) work out?

@@ -204,7 +204,11 @@ extension WorkflowNode.SubtreeManager {
func makeSink<Action>(of actionType: Action.Type) -> Sink<Action> where Action: WorkflowAction, WorkflowType == Action.WorkflowType {
let reusableSink = sinkStore.findOrCreate(actionType: Action.self)

let signpostRef = NSObject()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wonder if we should create a type which has the log... events and acts as a ref instead of creating an arbitrary object to act as ref.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤷 I'm not overly-concerned about it. We could make the log... calls member functions instead of static functions (and use the object as the object we use to look up the signpost ID. We'd have to figure out how to plumb that object around to the various places that need it.

I think this is fine for now. Thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant, creating something like:

class SignpostRef: AnyObject {
  func log(...)
}

But, this is just a nit, feel free to ship as-is!

@JustinDSN
Copy link
Contributor

Regarding the actions, I'm fine with either way as long as someone takes DRI to try and get the approval to add them in. I think it's very valuable, and likely that we'll get approval. My vote would be to keep them in with a comment to the followup work.

@AquaGeek
Copy link
Contributor Author

AquaGeek commented May 8, 2020

I changed the event logging to log the Workflow or Worker type instead of the event information.

Pros:

  • Can be public — we already log it with the other signposts
  • Easier to distinguish where an event came from (before you had to do the mapping yourself from event type -> Workflow/Worker type

Cons:

  • Less information

@AquaGeek AquaGeek merged commit 18c78b4 into master May 8, 2020
@AquaGeek AquaGeek deleted the stromberg/os_signpost branch May 8, 2020 17:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request swift Affects the Swift library.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add support for os_signpost
3 participants