Skip to content

Conversation

@jcchavezs
Copy link
Contributor

@jcchavezs jcchavezs commented Feb 16, 2018

This depends on #7

Ping @palazzem @vlad-mh @kevinlebrun

Copy link
Contributor

@kevinlebrun kevinlebrun left a comment

Choose a reason for hiding this comment

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

There are weird things going on around those micro-seconds time management. Are strings an option?

* @param Span $span
* @return array
*/
private static function spanToArray(Span $span)
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is this method declared static? Is an instance method not good enough?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good question, don't remember the answer but will check it out later.

return $arraySpan;
}

private static function encodeSpan(Span $span)
Copy link
Contributor

Choose a reason for hiding this comment

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

Same as for spanToArray.

}

if ($span->isFinished()) {
$arraySpan['duration_micro'] = 0;
Copy link
Contributor

Choose a reason for hiding this comment

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

It seems a little hacky. Why are you doing the replace inside encodeSpan? If it is a matter of int precision even with those rare 32-bit runtime you have more then 2000second to store the duration.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It was a matter of consistency. Since both start and duration are being stored as micro and then converted into nano when encoding, doing so only for start and not for duration seemed weird to me. If this bugs you too much we can have a chat and get into an agreement. WDYT?

'name' => $span->getOperationName(),
'resource' => $span->getResource(),
'service' => $span->getService(),
'start_micro' => 0,
Copy link
Contributor

Choose a reason for hiding this comment

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

It seems a little hacky.

{
$expectedPayload = <<<JSON
[[{"trace_id":"160e7072ff7bd5f1","span_id":"160e7072ff7bd5f2","name":"test_name","resource":"test_resource",
JSON
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is this concatenation necessary?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This was because maximum line length per file (linters). The way to avoid this is to ident the json fields but that screw up the comparison in line 31. Remember, we can't convert the json into array/object in order to compare it because of the lack of support for int64 in PHP.

@jcchavezs
Copy link
Contributor Author

jcchavezs commented Feb 27, 2018

Not sure about the string @kevinlebrun. @palazzem is it possible to send the start as string? Since agent is written in Python maybe it is possible?

@palazzem palazzem added the 🍏 core Changes to the core tracing functionality label Mar 1, 2018
@palazzem palazzem added this to the 0.1.0 milestone Mar 1, 2018
@palazzem
Copy link
Contributor

palazzem commented Mar 1, 2018

@jcchavezs actually the Trace Agent (written in Go) expects an int64 to decode the start field. Indeed if you try to send it as a string, you should get:

2018-03-01 15:35:37 ERROR (receiver.go:381) - cannot decode v0.3 traces payload: msgp: attempted to decode type "str" with method for "int"

This happens for the MsgPack Encoder, while for the JSON Encoder you'll get:

2018-03-01 15:38:28 ERROR (receiver.go:381) - cannot decode v0.3 traces payload: json: cannot unmarshal string into Go struct field Span.start of type int64

@jcchavezs
Copy link
Contributor Author

I guess since this is the only way to pass the int64 we can merge this PR. What do you think @kevinlebrun ?

@kevinlebrun
Copy link
Contributor

Yes, totally.

Copy link
Contributor

@kevinlebrun kevinlebrun left a comment

Choose a reason for hiding this comment

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

GTM.

@jcchavezs
Copy link
Contributor Author

@kevinlebrun @palazzem can you approve this PR?

@jcchavezs jcchavezs merged commit ec36532 into master Mar 1, 2018
@jcchavezs jcchavezs deleted the adds_encoders branch March 1, 2018 17:12
Copy link
Contributor

@palazzem palazzem left a comment

Choose a reason for hiding this comment

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

All good to me!

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

Labels

🍏 core Changes to the core tracing functionality

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants