Project

General

Profile

Actions

Feature #8706

closed

Permanent (pretty) URLs for error traces

Added by Vadim Mutilin about 6 years ago. Updated almost 6 years ago.

Status:
Closed
Priority:
Urgent
Category:
Bridge
Target version:
Start date:
02/06/2018
Due date:
% Done:

0%

Estimated time:
Published in build:

Description

We need to have a permanent ("pretty") URL for error traces which will not be changed during downloading/uploading job archives.
I think that for that purpose we can use job names provided by the users (seems that we need to enforce uniqueness of them) and a error trace number relative to the given job (it should be kept during downloading/uploading job archives).


Related issues 2 (0 open2 closed)

Related to Klever - Feature #10530: Improve representation of leaf reports and enhance capabilities for providing their attributesClosedVladimir Gratinskiy10/16/202011/19/2020

Actions
Blocked by Klever - Feature #8754: Require unique job namesClosedVladimir Gratinskiy03/13/201803/14/2018

Actions
Actions #1

Updated by Evgeny Novikov about 6 years ago

  • Description updated (diff)
  • Target version set to 2.0
Actions #2

Updated by Vladimir Gratinskiy about 6 years ago

Vadim Mutilin wrote:

We need to have a permanent ("pretty") URL for error traces which will not be changed during downloading/uploading job archives.
I think that for that purpose we can use launch names (identifiers) provided by the users (seems that we need to enforce uniqueness of them)

What does "launch names" mean? Identifiers of jobs? I didn't know that users can provide jobs identifiers.

and a error trace number relative to the given job (it should be kept during downloading/uploading job archives).

It can't be kept. I will use identifers specified in error trace json file (comments for "error traces" in https://docs.google.com/document/d/1tLOsqCQxMRlDvSNXFmaGOSQqIL8PORNI-BEsfZP8hoQ/edit). So the link will be like "/reports/unsafe/<32-bit error trace identifer>".

Actions #3

Updated by Evgeny Novikov about 6 years ago

  • Description updated (diff)

Vladimir Gratinskiy wrote:

Vadim Mutilin wrote:

We need to have a permanent ("pretty") URL for error traces which will not be changed during downloading/uploading job archives.
I think that for that purpose we can use launch names (identifiers) provided by the users (seems that we need to enforce uniqueness of them)

What does "launch names" mean? Identifiers of jobs? I didn't know that users can provide jobs identifiers.

I fixed the issue description. It's about job names. And it does have sense to make them unique globally, but this is responsibility of an user.

and a error trace number relative to the given job (it should be kept during downloading/uploading job archives).

It can't be kept. I will use identifers specified in error trace json file (comments for "error traces" in https://docs.google.com/document/d/1tLOsqCQxMRlDvSNXFmaGOSQqIL8PORNI-BEsfZP8hoQ/edit). So the link will be like "/reports/unsafe/<32-bit error trace identifer>".

I don't understand why this is necessary for the specified issue. Indeed Bridge can generate and use such the identifiers itself since they are required just for permanent and unique identification of error traces within various instances of Bridge (databases). Perhaps your approach can be helpful for debugging, e.g. when Bridge fails to visualize a given error trace and the developer needs to find it out somewhere in a Core working directory. But I guess that it isn't very necessary (I didn't remember the case when I needed this).

Actions #4

Updated by Vladimir Gratinskiy about 6 years ago

Evgeny Novikov wrote:

Vladimir Gratinskiy wrote:

Vadim Mutilin wrote:

We need to have a permanent ("pretty") URL for error traces which will not be changed during downloading/uploading job archives.
I think that for that purpose we can use launch names (identifiers) provided by the users (seems that we need to enforce uniqueness of them)

What does "launch names" mean? Identifiers of jobs? I didn't know that users can provide jobs identifiers.

I fixed the issue description. It's about job names. And it does have sense to make them unique globally, but this is responsibility of an user.

and a error trace number relative to the given job (it should be kept during downloading/uploading job archives).

It can't be kept. I will use identifers specified in error trace json file (comments for "error traces" in https://docs.google.com/document/d/1tLOsqCQxMRlDvSNXFmaGOSQqIL8PORNI-BEsfZP8hoQ/edit). So the link will be like "/reports/unsafe/<32-bit error trace identifer>".

I don't understand why this is necessary for the specified issue. Indeed Bridge can generate and use such the identifiers itself since they are required just for permanent and unique identification of error traces within various instances of Bridge (databases). Perhaps your approach can be helpful for debugging, e.g. when Bridge fails to visualize a given error trace and the developer needs to find it out somewhere in a Core working directory. But I guess that it isn't very necessary (I didn't remember the case when I needed this).

Ok, I'll generate identifiers myself.

Actions #5

Updated by Evgeny Novikov about 6 years ago

Actions #6

Updated by Evgeny Novikov about 6 years ago

  • Target version changed from 2.0 to 1.0

Let's hurry up this issue, since it is very high demanded, so, waiting for Klever 2.0 isn't good.

Actions #7

Updated by Vladimir Gratinskiy almost 6 years ago

  • Status changed from New to Feedback

Implemented in "new-report-data".

Actions #8

Updated by Evgeny Novikov almost 6 years ago

  • Status changed from Feedback to Resolved

This seems to work at least for a single instance of Bridge.

Actions #9

Updated by Evgeny Novikov almost 6 years ago

  • Status changed from Resolved to Closed

I merged the branch to master in 4339da97 as a part of branch core-new-formats.

Actions #10

Updated by Evgeny Novikov over 3 years ago

  • Related to Feature #10530: Improve representation of leaf reports and enhance capabilities for providing their attributes added
Actions

Also available in: Atom PDF