Project

General

Profile

Feature #8706

Permanent (pretty) URLs for error traces

Added by Vadim Mutilin about 1 year ago. Updated 9 months 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

Blocked by Klever - Feature #8754: Require unique job namesClosed2018-03-132018-03-14

History

#1 Updated by Evgeny Novikov about 1 year ago

  • Target version set to 2.0
  • Description updated (diff)

#2 Updated by Vladimir Gratinskiy about 1 year 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>".

#3 Updated by Evgeny Novikov about 1 year 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).

#4 Updated by Vladimir Gratinskiy about 1 year 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.

#5 Updated by Evgeny Novikov 12 months ago

#6 Updated by Evgeny Novikov 11 months 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.

#7 Updated by Vladimir Gratinskiy 9 months ago

  • Status changed from New to Feedback

Implemented in "new-report-data".

#8 Updated by Evgeny Novikov 9 months ago

  • Status changed from Feedback to Resolved

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

#9 Updated by Evgeny Novikov 9 months ago

  • Status changed from Resolved to Closed

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

Also available in: Atom PDF