Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
add throttle_state to tracking #2878
Thank you for your contribution! Sadly it looks like there is something wrong with this PR from your branch
Please take a look at the section on PRs in the Contribution Guidelines and make sure that your PR follows them. Thank you!
PS: I'm just an automated script, not a human being, so don't expect any replies from me :) Your PR is read by humans too, I'm just not one of them.
It is, but the bot doesn't know that ;) Ignore it...
First of all: I like the idea of adding info on the throttling state, great thinking!
There's still an issue though here since the current setup doesn't support nested data. This is how stuff arrives on the server:
So that structure needs to be flattened.
I'm also thinking it might be better to have the pi_support generate a custom event on status change and subscribe to that in the tracking plugin, and when the event is received send over the status update. That way it's easier to filter for, and the noise on the line is also reduced (our GET requests are limited in length as well by the HTTP spec).
Now, about the logging, I get where you are coming from, and I'm not against this, but it was done the way it was done for a simple reason: I don't want to see the instance UUIDs from people when they share their logs with me since that would de-anonymize them, and by logging this at INFO level I would ;)
How about modifying this to not include the URL after all, at least not on INFO level? I really don't want to get knowledge of any UUIDs if it can be avoided :)
Leaving this at "needs work" due to the two points above.
I know I can ignore the bot, but sometimes it's nice to talk back a little. :)
FWIW GET is probably limited to about 2k characters. Certainly the nested dict isn't helping. I reduced it to only send the
I know what you mean about sending it as an event, but it's sitting on about 20 characters now, which to me is worthwhile to not have to correlate GET requests to figure out if a failed print previously triggered overvoltage. Thoughts?
As you can see I removed the URL and added a note to explain it. I think that's a great way to go.
Pushing the code and testing locally over the next 24h, but wanted to put it up for discussion.
Nov 8, 2018
1 check passed
added a commit
this pull request
Nov 8, 2018
Why not both :D I added the events, so it's now possible to figure out how many throttled instances are out there without them needing to restart or print - for that I also added a new toggle so no one can complain there. And I also left the throttle state on the print events. Tested it against the backend and things are looking great.