In bug 1265709 I expressed the wish that Perfherder do away with the notion of the signature hash. Since I filed that, additional problems with this approach came up that convinced me more than ever that this is the right thing to do, for example bug 1309294. I've removed most of the client-side code that references signatures (with one small exception: https://github.com/mozilla/treeherder/blob/e513dd9a2e31e8f78507b4687f984b756726e6b2/ui/js/models/perf/alerts.js#L26), however the existing endpoints still return signature hashes as part of their payload. I think we'd be best off just replacing these with some new endpoints. These are also the only two performance endpoints that reference the project in the url, which is no longer really necessary. /api/performance/signatures/ (replacing /api/project/<projectname>/performance/sigantures/) ------------------------------------------------------------------------- Should take a very similar set of options to the current signature API, but instead of indexing by signature hash, just return a plain list. e.g.: [ { "suite": "tps", "machine_platform": "linux64", "framework_id": 1, "has_subtests": true, "id": 1305969, "option_collection_hash": "102210fe594ee9b33d82058545b1ed14f4c8206e", "extra_options": [ "e10s" ] }, { "suite": "glvideo", "machine_platform": "linux64", "framework_id": 1, "id": 1484241, "test": "Mean tick time across 100 ticks: ", "option_collection_hash": "f69e1b00908837bf0550250abb1645014317e8ec", "extra_options": [ "e10s" ] }, ... ] /api/performance/data/ (replacing /api/project/<projectname>/performance/sigantures/) ------------------------------------------------------------------------- Similar to the above. We now return 'signature_id' as part of each performance datum, which should let us say which signature the returned datum would apply to. To handle the one exception case I mention above, ensure that the /api/performance/signatures/ endpoint has enough query parameters to be able to quickly fetch the other equivalent signatures on other branches. -- I would initially implement this as a set of new APIs, keeping the old ones intact. After a transition period of 6 months or so, we could just retire the old APIs (and remove the signature hash from the performance datum db model?)