Comments (19)
Probably a two-phase upload. MT contacts the server and says, "Hi. I'm MT 1.4.1. I'd like to upload a crash log that's X bytes in size." The server can check that the message hash is correct and respond, "Ok. POST it to this URL." This will be a unpublished URL with a random number in the query string. Only valid, preauthorized random numbers will be allowed (meaning the first exchange has to work for the second to be valid).
I'l do this in PHP on the server side. Shouldn't be very tough. We can check for duplicates at this time as well. Might even be able to check for duplicates before uploading by having MT calculate a hash of the stack trace and sending that to the server; if the hash is already registered, we can tell MT that it's already been filed. Probably should hash it using the MT version number, since a bug that appears in two separate versions is something that should prod another look. :)
We should grab everything in the Help>Debug panel, but with any personal information scrubbed (usernames, home directory?).
How do we want the information going to developers? Do we dump the log in a directory on the server and post a message to Slack or Github or something? Or maybe there should be a WordPress interface so that the UI is a little nicer than a directory listing? Do we want to make it visible to users in a way that they could file an issue in GitHub and then link to the stack trace? Do you think our users would go through that effort?
from maptool.
I like this approach. My opinion would be to open a GitHub issue for it, with a link to the zip of logs/info. If personal info is scrubbed a public link shouldn't be an issue. If the same stackTrace is already submitted, add a comment to the issue for the log link. Add tags to the issue for version # and OS.
You can then report back the user with a URL to the github issue. They don't need a login to see them, only to comment.
from maptool.
FYI there is a php lib for the github api
from maptool.
Okay.
I'm thinking the uploaded zip file should contain a text file with the stack trace and a separate file with the contents of the debug panel. I think the checksum for the file inside the zip should be enough to uniquely identify the content and I don't need to calculate a separate checksum/hash on the content.
Lastly, the MT version number may not be enough when there are betas floating around; for example, if I use a custom build for a home game. Is there a (simple) way to put the git commit hash somewhere that MT can get to it? Then MT can report it's version number but also it's git commit entry to be really specific... It could be the same properties file as the MT version and other particulars...?
from maptool.
Gradle could insert the commit into a file but of course, we could never guarantee you were not building from eclipse without committing...
We should only enable reporting on production versions? Custom builds should do their own debugging?
from maptool.
We also talked about splitting dev builds into a separate build/install so those would be unstable production builds and should be reported and we can tag them as such.
from maptool.
In my opinion, changing build methodologies between dev, test and prod is bad juju
from maptool.
Eh? I'm just talking about allowing dev build to install next to prod version with separate settings/.maptool folder
from maptool.
I really hope I can edit that comment when I get home.
So same build for dev/test release to non-devs. That's good.
from maptool.
Using octodroid? U can edit...
And ya. I was just stating that a custom/interim build should not report.
from maptool.
Agree completely. Also, it would be good if the various forks out there didn't report when someone forks for their own use/product. For that matter, it would be nice if those didn't report in server stats either.
from maptool.
Craig will have to sign the official releases.
from maptool.
They don't need to be signed, we just need to use a hash digest that uses a seed that only we know. If any other version of MT were to connect, our server side tool would reject it as invalid.
from maptool.
@Azhrei & @cwisniew
Going through some older issues and this reminded me...
Currently I use https://sentry.io for Nerps. Granted there is some noise as it does get a lot of stack traces I haven't had time to look into but anyhoo...
What do you guys think about using it for RPTools repo? Currently 1.5 IS setup to be able to use this. Currently there is a .properties file that holds a DSN for a sentry.io account and this is blank for now (so it will NOT send any info)
To enable it, we would need to create a new account for RPTools. And I would think, probably at least a popup or something to ask the user? Would a "checkbox" on the existing stacktrace window, default to off, be good enough and save this checkbox to AppPreferences?
from maptool.
Would it be logging only exceptions? If so, the we wouldn't need a pop up, IMO. Just the checkbox that says, "send to the development team from now on" or something. When they close the panel, send it if the checkbox is turned on. Is that what you were thinking of?
from maptool.
Yeah. Right now it logs the stack traces but also sends the server settings so I think we get maybe the PC name? We also get OS and the client name as [email protected] as the email.
And ya, was thinking just that, a send to Dev team check box.
FYI sentry.io can create GitHub issues from the stack traces. It's pretty slick.
You get like 5000 a month IIRC and has spike protection.
from maptool.
I think that'd be great. Maybe add a textarea so that the user can describe what they were doing when the crash occurred? I would think the stack trace would be enough in most cases, but sometimes we get those traces that are results of an expose event in the GUI and then the trace is pretty much useless; user input would be necessary.
Is there any value in feeding the DSN to MapTool from our web site? So when someone runs MT, it connects to RPTools.net and we give them a DSN. I can't imagine we'll hit 5k/month (at least, I certainly hope we don't!), but if it happens, it might be nice to switch other events to another DSN. If we had two or three, we could round-robin the one we hand out to MT at startup, meaning we'd have 15k at that point.
And maybe we should start keeping a history of the last few error messages and including them in the report. Whenever MapTool.showError()
is invoked, just add to a list. The macro engine should maybe do the same thing...?
Anyway, short term we turn it on and use it. Long term, we consider the other stuff. :)
from maptool.
I like that idea, a text box would be a good addition.
IIRC it will also send and stack traces that gets logged (it's controlled by the log4j2 config)
And I have it so Dev mode doesn't log to sentry, only production.
I think if we get over 5k it's probably the same stack over and over so it should inspire is to fix it? :)
from maptool.
We have sentry enabled. So we can close this I think.
from maptool.
Related Issues (20)
- [Refactoring]: Campaign Properties - Reworking Token Properties Edit Table HOT 11
- [Feature]: Exploding Dice Limit
- [Feature]: Adjust UI spacing in token properties and Include option for old style entry HOT 2
- [Bug]: Java Exception when Editing Campaign Token Properties
- [Refactoring] Consolidate duplicate label i18n strings
- [Bug]: Lib:Token can no longer be found
- [Bug]: Trusted macro output colours preferences do not display HOT 1
- [Feature]: Update Text Labels to make them easier to read. HOT 11
- [Bug]: Cursor for VBL drawing does not change when tokens have alternate statsheets
- [Feature]: General base number instead of fixed 5-feet for all distance calculations
- [Feature]: Allow a text file to be dragged from the Library onto a map as a token through which the text data (any form of text data) can be accessed and parsed.
- [Feature]: Optional Additive Lights
- [Feature]: Custom Events
- [Feature]: Add Token Types in getInfo("campaign") HOT 1
- [Bug]: library.getContents() sometimes returns an empty JSON array
- [Feature]: MapTool should offer to reconnect when an error causes a server disconnect
- [Feature]: Have Campaign Properties>Token Properties tab remember last selection. HOT 1
- [Bug]: Disappearing text labels in imported map from older version HOT 1
- [Bug]: Opening older campaign, text labels move and have invisible text color HOT 1
- [Bug]: Error adding add-on with new stat-sheet HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from maptool.