One of Balrog's big selling points is the history it provides, which (theoretically) lets us see what was going on at any point in time. In practice, this can be very tricky for a few reasons: - To effectively see which Rule a request was hitting, you need to see the state of the entire Rules table. The current UI doesn't provide any easy way of doing this. - Even if you're able to figure out which Rule the request was getting, the underlying Release that it maps to may have changed since the request was made, so you need to rewind the Release it maps to. - Even once you have _that_, you may need to also rewind the Releases referenced in "partials". I've been wondering if it might be possible to have an optional timestamp be passed in the query args of the update request. With this, we could retrieve an entire old version of the rules table to parse, retrieve older releases, etc. Probably needs some thinking about potential security impacts, as it may make downgrade attacks possible. Perhaps we'd want to disable this feature for production domains, but set-up a new domain against the production db with it enabled. *handwave*

bug 1316948 would help here

I'm a bit concerned about potential DoS possibilities if we add support for rewinding the Rules to a publicly available domain -- the history tables can be expensive to query and process results from. Between that, and the potential downgrade attack concerns here, I'm leaning more towards putting this on the admin api instead of the public one. I also realized even after rewinding the tables we may not give a fully accurate answer -- it's possible that the xml construction code may have behaved differently eg: a year ago. This bug is probably less urgent after we fix bug 1329524, which is easier and safer anyways.