Do not publish notifications for problems with solutions

[jfilak]

Maintainers and developers do not appreciate notifications for problems caused by locally build programs.

[jfilak]

https://retrace.fedoraproject.org/faf/reports/1122925/

[sorki]

How come this even reported to FAF? Also seems to be leaking username..

[jfilak]

How come this even reported to FAF?

Because the private path hashing is implemented only in FAF:
commit 0f9b0b4

and the action is not in crontab.

[sorki]

The reason why that action exists is because the CLIENT side leaked such paths in the past. It's not designed to be run via cron but only as a remedy to previous leakage of private paths.

[patriczek]

Hi

I want solve this problem, and the best solution what i invented is:
When uReport come on FAF Server from client i'll check if exist any solution, if yes then i will add solution id into uReport.

Also i added column 'solution' to table 'reports' in database where i save solution id while are uReports saving to database. This will allow us to easy control which report will send notification.

[jfilak]

When uReport come on FAF Server from client i'll check if exist any solution, if yes then i will add solution id into uReport.

Do I understand it correctly that you are going to add some data to received reports?
Why do you need it?

Also i added column 'solution' to table 'reports' in database where i save solution id while are uReports saving to database.

We follow the "${table_name}_id" schema for naming foreign keys. Do I get it right that you are going to introduce 1:M relation between solutions and reports?

This will allow us to easy control which report will send notification.

How? Why?

[patriczek]

Do I understand it correctly that you are going to add some data to received reports?
Why do you need it?

Yes you understand correctly, i need it because we find solution when new report come to FAF and IMHO it's better to add one attribute to the uReport, than looking again for solution while saving reports.

We follow the "${table_name}_id" schema for naming foreign keys. Do I get it right that you are going to introduce 1:M relation between solutions and reports?

Ok change the name of column is easy. And you have right about mapping.

How? Why?

Because of we will have marked all reports which have solution in database and we can easy filter this reports in database.

[patriczek]

But here is problem, because we don't have all solution saved in database so i can't link all reports with solution (e.g: Probable Fix Solution ).

IMHO i can all solutions which aren't in database insert at first occurrence into database or do you have any better solution?

[jfilak]

Yes you understand correctly, i need it because we find solution when new report come to FAF and IMHO it's better to add one attribute to the uReport, than looking again for solution while saving reports.

So you need to do that because FAF looks for solutions upon receiving a new uRerpot, than FAF saves the report in a temporary file and after a short period of time FAF pushes the temporary uReport files to the database. The notifications are emitted during processing of the temporary report files while the solutions are looked up at receiving.

And you have right about mapping.

Please, document this decision.

I'm not sure adding a new column to report table is a good idea. Other additional information like external URLs are stored in separate tables. How often do we need this information available?

Because of we will have marked all reports which have solution in database and we can easy filter this reports in database.

Why it is not enough to check if the processed report has a solution assigned during processing of the temporary files? Why do you need to store the report solution in database?

[patriczek]

I'm not sure adding a new column to report table is a good idea. Other additional information like external URLs are stored in separate tables. How often do we need this information available?

We want to make #503 and #504 so we need this information everytime when will loaded page with reports/problems.

Why it is not enough to check if the processed report has a solution assigned during processing of the temporary files? Why do you need to store the report solution in database?

It could be enough, but IMHO it's not necessary to find solution 2 times when i can just add one row into temporary file while is creating.
We need store the report in database because we want showing the solution in report/ problem page #504 also i think it will take less HW resource than finding solution on every request.

[jfilak]

But here is problem, because we don't have all solution saved in database so i can't link all reports with solution (e.g: Probable Fix Solution ).

Probable Fix Solutions is a special case, because we want to show probably fixed reports/problems to users and we want to notify probably fixed reports.

IMHO i can all solutions which aren't in database insert at first occurrence into database or do you have any better solution?

What exactly do you want to insert into database for Probably Fix Solutions?

[patriczek]

Probable Fix Solutions is a special case, because we want to show probably fixed reports/problems to users and we want to notify probably fixed reports.

Ok then i think this is solved..

[jfilak]

Ok then i think this is solved..

In #504 I asked for showing solutions on the report/problem page, so I am wondering how are you going to display Probaly Fix Solutions?

[jfilak]

I have to change the goal of this issue. We need to stop notifying maintainers about reports that are considered as "not-reportable" by ABRT.

[patriczek]

Unfortunately, I don't know what is means "not-reportable" so i can't propose any solution.

[patriczek]

After a discussion with @jfilak we came to a decision how to split type of solutions.

From our point of view is the best solution try to approach solution format as much as possible to https://github.com/abrt/faf/wiki/Improved-solutions-protocol format. So i will extend solutions by missing attributes (type, certainty, title) which will help me distinguish if is report "reportable" or not. This means i will need a little bit edit every existing solution.

Because of we can't link report with solution because of every solution have separate database table or don't have any table i want mark reports as "have solution". This will serve as optimization for next issues #504, #503, where is necessarily looking for solution in real-time. This will be made by adding certainty into reports table in database. Then i'll know if is necessarily trying find correct solution or not.

[marusak]

@jfilak @patriczek Is this issue fully solved by #526 ?

[xsuchy]

I guess we can mark this as solved.