FogBugz Technical Support

A forum for technical support discussion related to Fogbugz.
The current FogBugz Knowledge Base can be found at http://help.fogcreek.com/fogbugz.

Posts by Fog Creek Employees are marked:

Documentation
Release Notes
Network Status

Scout Reopening Bugs

With some bugs, 1 error message may represent a number of different bugs.  For example: "NullReferenceException - Object reference not set to an instance of an object." is a bug in our system with 11 occurrences over the last 6 months. None of them the same. Each of them reopening the same closed bug. :)

We need a 3rd "Scout Will" option for "Force New" that will tell scout to still accept the report, but /not/ reopen an existing bug.

Right now we're stuck either cutting & pasting the latest NullRef report into a new bug and closing the old one again and again.

We don't want to always have Scout for new because when a common bug hits we would be inundated with duplicates. Our last release had a major bug that we missed in Q/A. It generated a ton of reports within minutes. So we need it to append, we just need to control how it does so.

Thanks
Marc LaFleur Send private email
Friday, March 4, 2005
 
 
Why not include the line number or function name in the error description?  Then the same bugs will go to the same place, and different bugs will go to a different place.

That's how BugzScout is designed.  It uses the Description as a unique key for deciding whether or not to open a new bug or append to an existing one.
Michael H. Pryor Send private email
Friday, March 4, 2005
 
 
Because I often don't have that information. This is often true of exceptions coming off an ASP.NET WebService.

Other times it is an error stemming from a 3rd party product so I'm stuck with whatever info they give back to me. We have a case of this right now where 3 separate issues are being sent back with the same description (only the trace information is different).
Marc LaFleur Send private email
Friday, March 4, 2005
 
 
Also, I do understand that this is how Scout works. But I'm limited to stopping it from reporting entirely or appending. I just want to be able to have it create new as well.
Marc LaFleur Send private email
Friday, March 4, 2005
 
 
If you send FogBugz the same Description every time, how would it know whether to create a new bug or not?  Since it uses that field as the key, the only other option is for your program to pass a value that says "Make this a new case", which is what the ForceNewBug value is for.  Wouldn't it be possible to have your program just set ForceNewBug to be true when it catches those generic exceptions?

We can't use the entire report as a unique key because people have different data they would want to return about the same exact crash.
Michael H. Pryor Send private email
Saturday, March 5, 2005
 
 
You already have the mechanism in place for this.

Currently I can set how scout responds. It either "continues reporting" or "stop reporting". I want to have a 3rd option "continue reporting, stop appending"
Marc LaFleur Send private email
Monday, March 7, 2005
 
 
A simple solution would be to just append the current date and time to the title of the case, that way there will never be a duplicate.
Lasse Vågsæther Karlsen Send private email
Wednesday, March 30, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz Bug Tracking and Evidence-Based Scheduling.