fixed case #131
fixed case #131
Conversation
instana/json_span.py
Outdated
| Type = None | ||
| type = None | ||
| arguments = None | ||
| Return = None |
There was a problem hiding this comment.
Nice catch. Shouldn’t we do the same with Return? Also: I think we should fix it backend side too as this does not handle already compiled GoLang executables.
There was a problem hiding this comment.
Good point I was so focused on the Type I missed Return. Just committed that too.
I'm just started to look at Golang to see if it has the same problems.
It would be quite a big change on the backend to make it case insensitive and could have performance implications due to the high volume of traces processed.
|
At one point there was a reason why we couldn't lowercase this field: 396a279 I'll take another look at this today. Thanks for the PR! |
|
Peter,
Could be a Python 2.x thing? I only tested with Python 3.x
Regards,
Steve Waterworth
s@steveww.org
… On 15 Feb 2019, at 12:18, Peter Giacomo Lombardo ***@***.***> wrote:
At one point there was a reason why we couldn't lowercase this field: 396a279#diff-92b2d0cde86ecf3b3bb28fe5e95496d6 <396a279#diff-92b2d0cde86ecf3b3bb28fe5e95496d6>
I'll take another look at this today. Thanks for the PR!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#131 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFK3nqYmiuX83i6IBZzd9WYMedM5gfiIks5vNqWXgaJpZM4a9f3D>.
|
|
No - the backend has evolved and we haven't followed. Fixing this today. I'll might have to create another branch/PR to make sure we properly report |
|
Ah I remember now :-) lowercase |
3 participants
The type field for the SDK data object had the wrong case Type not type. The trace processing on the backend does a case sensitive lookup of this field. It does not find Type so tags the span as entry, the default. This makes it impossible to have an intermediate span, this fixes that.